From ram-bounces@iab.org Thu Feb 01 03:52:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXda-0005rD-3Y; Thu, 01 Feb 2007 03:49:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCXdZ-0005r6-0l for ram@ietf.org; Thu, 01 Feb 2007 03:49:45 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCXdS-0006HK-Ks for ram@ietf.org; Thu, 01 Feb 2007 03:49:45 -0500 Received: from [84.241.203.196] ([84.241.203.196]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l118mDJR075982 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 1 Feb 2007 09:49:28 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <7F9645B9-7025-4037-BB63-A1C756317B23@alcatel.com> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> <7F9645B9-7025-4037-BB63-A1C756317B23@alcatel.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8AA19C66-234E-476D-96F5-3A25A4CE1C3A@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] be afraid... Date: Thu, 1 Feb 2007 09:48:39 +0100 To: Andrew Lange X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 31-jan-2007, at 22:56, Andrew Lange wrote: >> For instance, for VoIP it's important to give VoIP traffic a >> higher priority than some other types of traffic. > This point is often made, but without too much consideration as to > where prioritization is useful. Priority schemes are useful ONLY > when there is contention for resources on the line. Very true. > A network is usually designed to handle peak loads without > congesting (mother's day load in the US voice networks), after all > a carrier does not want to turn away business if they don't have to > do so. That's nice in the phone world where every call makes you money, but not so much in the IP world where revenue and traffic aren't related for large classes of customers. (I.e., a residential user pays the same whether they only check their email once a day or run BitTorrent 24/7.) Also, many kinds of IP traffic take as much bandwidth as they can. For those applications, there must be a bottleneck or other limiting factor somewhere as long as they're transferring less than a gigabyte per round trip. First Law of Van Beijnum: there is always a bottleneck. In more concrete terms: the link from a customer to an ISP is very often a bottleneck, even if only intermittently. Bottlenecks inside ISP networks and in the interconnection between different ISPs are relatively rare but happen. > In the most usual state the network will have resources available > in most places. Very reassuring. :-) >> For outgoing traffic this is easy to do by looking at port numbers >> or diffserv code points, but for incoming traffic that's much >> harder: essentially, you need to tell an ISP how to deal with >> different kinds of traffic in a great amount of detail. > The issue here is not a technical one, it is an issue of trust. No, it's not a question of trust. If you trust your ISP enough to give them your money then that part is taken care of. The issue is one of transferring and maintaining detailed state. ISPs don't like this because it makes their equipment more expensive and it requires complex protocols (intserv anyone?). > Does your operator trust you to mark your VoIP packets correctly, > and in a way meaningful to that operator? If your operator is like > those I have experience with, then the answer is no. If I want to do this for incoming packets, that means I must push out filter rules to my ISP so they can color the packets correctly before they hit a bottleneck. This isn't easy to do. For outgoing packets, I don't necessarily see a problem. If I were an ISP, I would probably like a model with three traffic classes: - bulk: all you can eat, but I'll drop packets when and where I want - best effort: I won't arbitrarily drop these packets, no metering but fair use policy: if you do too much traffic of this type I may bump down your priority to bulk - high priority: gets preferential treatment but billed per megabyte This way, users can decide how important packets are, and I take my cues from them so no distrust is required. >> Maybe others have a better view of this, but it's completely >> unclear to me how real time traffic over the internet is going to >> play out in the future. > There will be a network of bilateral peering arrangements between > networks Bilateral doesn't scale. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 01 04:26:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYCB-0001KX-Ik; Thu, 01 Feb 2007 04:25:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCYCA-0001KS-UA for ram@iab.org; Thu, 01 Feb 2007 04:25:30 -0500 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCYC9-0000UK-Hl for ram@iab.org; Thu, 01 Feb 2007 04:25:30 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate6.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l119PQ0r274826 for ; Thu, 1 Feb 2007 09:25:26 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l119PQ541646702 for ; Thu, 1 Feb 2007 09:25:26 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l119PPms009951 for ; Thu, 1 Feb 2007 09:25:25 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l119PPE9009914; Thu, 1 Feb 2007 09:25:25 GMT Received: from [9.4.211.7] ([9.4.211.7]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA251546; Thu, 1 Feb 2007 10:25:24 +0100 Message-ID: <45C1B205.6050905@zurich.ibm.com> Date: Thu, 01 Feb 2007 10:25:25 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: RJ Atkinson Subject: Re: [RAM] Re: server referrals References: <4E0BE885-C751-4F46-AC1B-1E1E0B971D5B@extremenetworks.com> In-Reply-To: <4E0BE885-C751-4F46-AC1B-1E1E0B971D5B@extremenetworks.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-31 16:32, RJ Atkinson wrote: > Earlier Thomas Narten wrote: >> IMO, this assertion needs to be shown to be true. >> I suspect its very much not. > > Well, if one is looking to prove assertions, let us please start > with proving the unsubstantiated assertion that server referrals > necessarily are broken by moving to an ID/Locator split. Actually it might be exactly the opposite: referrals are widely broken today by NATs and VPNs (which both cause addresses to have a limited context of validity) whereas I assume that any loc/id split will at least have the virtue of providing global ids. To put it another way, we should make this a requirement: ids must be able to serve as 3rd party references. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 01 05:42:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZNB-0005LO-7P; Thu, 01 Feb 2007 05:40:57 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCZN9-0005LI-CY for ram@ietf.org; Thu, 01 Feb 2007 05:40:55 -0500 Received: from giss7.seg-social.es ([194.179.55.129] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCZN7-0008Ot-UQ for ram@ietf.org; Thu, 01 Feb 2007 05:40:55 -0500 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JCS5NO00.56W; Thu, 1 Feb 2007 11:40:36 +0100 In-Reply-To: <8AA19C66-234E-476D-96F5-3A25A4CE1C3A@muada.com> X-Priority: 1 (High) Subject: Re: [RAM] be afraid... To: Iljitsch van Beijnum X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 1 Feb 2007 11:40:33 +0100 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 01/02/2007 11:40:35 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable X-Spam-Score: 0.3 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch: See my comments inline. Regards, Iljitsch van Beijnum escribi=F3 el 01/02/2007 09:4= 8:39: > > On 31-jan-2007, at 22:56, Andrew Lange wrote: > > (deleted) > > >> For outgoing traffic this is easy to do by looking at port numbers= > >> or diffserv code points, but for incoming traffic that's much > >> harder: essentially, you need to tell an ISP how to deal with > >> different kinds of traffic in a great amount of detail. > > > The issue here is not a technical one, it is an issue of trust. > > No, it's not a question of trust. If you trust your ISP enough to > give them your money then that part is taken care of. The issue is > one of transferring and maintaining detailed state. ISPs don't like > this because it makes their equipment more expensive and it requires > complex protocols (intserv anyone?). I think it's a question of service definition: an ISP could provide a data service of up to 2Mb/s with a maximum of 128Kb/s of priority traffic. This doesn't require a complex configuration but only to configure the traffic conditioning for the offered data service. Then, when you exchange priority data with another user the quality of the service that you experience will depend on whether the other user has paid its ISP for a data service with a priority bandwidth or not. > > > Does your operator trust you to mark your VoIP packets correctly, > > and in a way meaningful to that operator? If your operator is like= > > those I have experience with, then the answer is no. > > If I want to do this for incoming packets, that means I must push out= > filter rules to my ISP so they can color the packets correctly before= > they hit a bottleneck. This isn't easy to do. If the other user has paid for a data service as the one I mentioned before, there is no need for you to push any filter rule because your ISP will deliver priority traffic according to your contract. > > For outgoing packets, I don't necessarily see a problem. If I were an= > ISP, I would probably like a model with three traffic classes: > > - bulk: all you can eat, but I'll drop packets when and where I want > - best effort: I won't arbitrarily drop these packets, no metering > but fair use policy: if you do too much traffic of this type I may > bump down your priority to bulk > - high priority: gets preferential treatment but billed per megabyte > > This way, users can decide how important packets are, and I take my > cues from them so no distrust is required. > > >> Maybe others have a better view of this, but it's completely > >> unclear to me how real time traffic over the internet is going to > >> play out in the future. > > > There will be a network of bilateral peering arrangements between > > networks > > Bilateral doesn't scale. I don't see why the kind of bilateral data service contracts that I explained above would not scale. Regards, Juanjo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 01 08:19:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbon-000771-OA; Thu, 01 Feb 2007 08:17:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCbom-00076w-K5 for ram@ietf.org; Thu, 01 Feb 2007 08:17:36 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCbol-0005Sy-9G for ram@ietf.org; Thu, 01 Feb 2007 08:17:36 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 01 Feb 2007 05:17:33 -0800 X-IronPort-AV: i="4.13,266,1167638400"; d="scan'208"; a="384695105:sNHT2607798500" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l11DHXd4022895 for ; Thu, 1 Feb 2007 05:17:33 -0800 Received: from [10.31.2.30] (sjc-vpn4-221.cisco.com [10.21.80.221]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l11DHWho008581 for ; Thu, 1 Feb 2007 05:17:32 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <45C11CC4.1050503@tm.uka.de> References: <31C6BA1C-F96B-4251-B558-86C088B49F89@cisco.com> <0CACBFDE-42A8-4152-A412-993E6742E1C1@inetcore.com> <45C07607.9040501@zurich.ibm.com> <65E1D3E6-1DED-4240-85F3-27F32F6904C6@alcatel.com> <45C11CC4.1050503@tm.uka.de> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0721B6F2-6768-42B2-9C57-59EE98F1E374@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] be afraid... Date: Thu, 1 Feb 2007 05:16:13 -0800 To: ram@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1066; t=1170335853; x=1171199853; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20be=20afraid... |Sender:=20; bh=GxD42FQgdYGjAP8SKXm9jxgMZ7dXZmE7Uq630u44I4A=; b=EJG4QsczlhFGk6HovjxGUxxG+lrUp2+zaTEQD7gPfbpfa4Py2lKV26gmmpmUh7hKL17uajVH oHmmv3YZa3V4EdxjwBqbSxqHaUIQl7LoJCYQamttl5koUcufIzpBfxwC; Authentication-Results: sj-dkim-7; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Jan 31, 2007, at 2:48 PM, Roland Bless wrote: > So I know at least one provider that introduced prioritized > VoIP traffic in order to protect it against congestion > caused from "normal" traffic, e.g. caused during DDoS flooding > attacks (congestion may be caused in the direction > towards access networks, i.e. when descending the bandwidth > hierarchy). This makes sense to me... Yes, this is pretty much the only application of QoS to flooding attacks which isn't self-defeating, assuming you've fixed endpoints to deal with, assuming you've implemented antispoofing, and assuming the systems for which you've reserved said bandwidth aren't themselves compromised. If all of the above aren't true, then the QoS can be self-defeating as the bad 'reserved' traffic chokes out the good. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 02 15:39:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HD57I-00023j-NX; Fri, 02 Feb 2007 15:34:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HCQ0S-0003Py-Qn for ram@iab.org; Wed, 31 Jan 2007 19:40:52 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HCQ0R-0006YB-Ui for ram@iab.org; Wed, 31 Jan 2007 19:40:52 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Jan 2007 16:40:51 -0800 X-IronPort-AV: i="4.13,264,1167638400"; d="scan'208"; a="107623650:sNHT64741437" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l110epXV030022; Wed, 31 Jan 2007 16:40:51 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l110egDm013473; Wed, 31 Jan 2007 16:40:51 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 16:40:45 -0800 Received: from [192.168.1.114] ([10.21.88.213]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 31 Jan 2007 16:40:44 -0800 In-Reply-To: <45BE2530.2050600@piuha.net> References: <45BE2530.2050600@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Wed, 31 Jan 2007 16:40:43 -0800 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Feb 2007 00:40:44.0483 (UTC) FILETIME=[9B84C130:01C74599] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=14806; t=1170290451; x=1171154451; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20thoughts=20on=20draft-farinacci-lisp-00 |Sender:=20; bh=7V22EA56PjCi4KWSKPtsQRaA87HJd16fhWKYneou8RY=; b=unt6EB3Y5+57cGnkqog76BEPK0MF6BO4rorVchySfgOgyxdC8U0s52EpV00XqRkBEhl3604J PiBWBNvlmOaF8278cxgfP9kIYF7b9HzbAm3aM7W891dvJzH1QBA40XoJ; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1df8e4abc9851cb4adb45bd64d8514ae X-Mailman-Approved-At: Fri, 02 Feb 2007 15:34:39 -0500 Cc: Dino Farinacci , ram@iab.org Subject: [RAM] Re: thoughts on draft-farinacci-lisp-00 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I took the liberty to cc my coauthors. And I apologize in advance for the long reply. > I read the draft and was quite happy with > it in terms of something that is intended to > be a base for experiments. A couple of Thanks for your comments Jari. See my responses inline. Sorry this took some time to respond to. > observations and questions, however: > >> LISP > As an old Lisp hacker, I like the name of your > proposal :-) Now, if you can also name the > addresses as CARs and identifiers as CDRs > (or maybe that's CIRs)... We tried but it just wouldn't work. But taking the CDR of the encapsulated packet in the ETR does decapsulate the packet and taking the CAR of the pre-encapsulated packet in the ITR sends just the header. ;-) >> The operator community has requested that the IETF take a >> practical >> approach to solving the scaling problems associated with global >> routing state growth. This document offers a simple solution >> which >> is intended for use in a pilot program to gain experience in >> working >> on this problem. >> >> The authors hope that publishing this specification will allow the >> rapid implementation of multiple vendor prototypes and >> deployment on >> a small scale. Doing this will help the community: >> >> o ... >> > I very much agree with the approach of testing practical > solutions and getting experience on what the hard > issues really are. Thank you for writing up your > prototyping/experimenting plans; we should have > more drafts that take this approach. You are most welcome. We gotta have a little fun, shouldn't we? ;-) >> load-splitting across its members. > Is load-splitting a requirement from a traffic > engineering perspective? What is the impact > from the point of view of the same TCP > session ending up going over multiple > paths? Note that most of the end-host > multihoming work has punted this > question by stating that load-balancing > is out of scope. This can be optional. It gives better failover, like ECMP does in routing today. We wanted the frequency of EID-to-RLOC changes to be extremely low and not take into account reachability. We wanted to track reachability outside of the mapping function. > Or is there something that you can > do to avoid the problem with TCP, such as > requiring that traffic from the same EID > source/destination pair can never be split > across paths? Yes, we can. We can latch each EID/32 (or EID/128 in IPv6) to a specific RLOC. Just like we hash today in routers forwarding on ECMP paths. >> 3. In LISP 1, the packet is routed through the Internet as it is >> today. In LISP 1.5, the packet is routed on a different >> topology >> which may have EID prefixes distributed and advertised in an >> aggregatable fashion. In either case, the packet arrives at the >> ETR. > I like this, because it means that applications > that are unaware that they are dealing with > EIDs can leak them to other hosts, and those > hosts will still be use the EIDs, because they > are routable. > > However, presumably this means that for > LISP 1, there is no change in the size > of the routing table needed in the global > Internet. Every site has to be able to be > reachable with EIDs. We have plans to forward packets with EIDs on another topology. One that is possibly slower performance that can have a strict hierarchy of EID-prefix aggregation. That does not suffer the multi-homing attachment point problem or need more-specific route injection for TE purposes. This could be: o Server based (like send data packets to 7 root servers for instance) o A separate tunnel topology o A separate VRF that runs on very small subset of the existing BGP peering topology o A separate SAFI or maybe even a separate AFI? o DHTs o Others? > (Conversely, in LISP 3 & 4, you would > have the application referral problem.) Yes, you are right. But we need to consider it for the PI-advocates. >> RLOC unreachability is >> detected by the receipt of ICMP Host Unreachable messages. When an >> RLOC has been determined unreachable, it is not used for active >> traffic; this is the same as if it is listed in a Mapping Reply with >> priority 255. > I'm a bit uncomfortable with relying solely on > ICMP for this function. What happens if something > filters it away, will you be able to recover? Well we received a lot of input on this. And I polled about 20 people from differing backgrounds. We are split. People say, we will just punch holes and don't worry about it. I offered encapsulating in ESP which has a hole punch in almost every firewall I have heard of and use a null cipher when you don't want to use authentication. And when you do, figure out a way to find keys. So we are inclined to not change it at this point. During prototyping the truth will be told (no matter what the experts say ;-)). > Also, the failure/reachability part probably needs more > work in general. When do you switch back from a situation > where the RLOC has been determined as unreachable? When you get a reply from the ETR's unreachable RLOC, you can probe with an ICMP EID-to-RLOC request to see if it is replied to. Of course, you must rate limit and send requests for *EID-prefixes*. The request must cover a course-grain EID. >> LISP is designed to be very hardware-based forwarding >> friendly. By >> doing tunnel header prepending [RFC1955] and stripping instead >> of re- >> writing addresses, existing hardware can support the forwarding >> model >> with little or no modification. Where modifications are required, >> they should be limited to re-programming existing hardware rather >> than requiring expensive design changes to hard-coded >> algorithms in >> silicon. >> > > Sounds good. Well, if we want to solve the problem quickly, we have to think of these things. >> EID-prefix-to-Locator mappings need to be explicitly configured. > Can you expand on what this means? So, for instance, in > the first hop router case, what would we have to > configure? The EID prefix advertised in the local network -- > but wouldn't we have to configure a prefix anyway? > Or the mapping between the router's RLOC and this > prefix? But even that might be obvious, assuming > that the Lisp feature is turned on and that you have > one prefix in the local network and one RLOC from > higher up... In the ITR, you configure this: o The EID-prefix is a course route that goes into the RIB/FIB. This route escapes traditional packet forwarding so LISP header prepending can happen. For local destinations, there are more specific routes in the IGP that cause packet forwarding to occur with no header prepend. o The RLOCs for the ITR must be specified. In a cisco implementation I am thinking it can point to a loopback interface, so those addresses are the source RLOCs for sending LISP encapsulated packets. In the ETR, you configure this: o The EID-prefixes you must respond to with an ICMP EID-to-RLOC Reply. This again is an escape from the FIB for the case when the outer IP destination address is the same as the inner IP destination address. In the case the RLOC is the outer address, the packet is naturally decapsulated because the outer IP destination address is one of the ETR's assigned local addresses. o The RLOCs for the ETR must be specified so you know what to return in bullet one, and for ICMP EID-to-RLOC Request messages. Again, loopback interface addresses. In the case where the site might want more than one ETR (you might want one CE connected to ISP-A to be a ETR and another CE connected to ISP-B to be the other ETR), then each ETR configures the RLOCs for all ETR boxes. This way you don't have to deal with a append-versus- replace semantic. That is, the latest ICMP Reply received always replaces previously stored information. So I think in the normal case, we might get away with 1 EID-prefix per AS with exactly 2 RLOCs associated with that EID-prefix (data from Geoff Huston indicates 80% of multi-homed stubs are dual-homed). This way we can keep the request overhead down by just probing for the first host that talks to the first destination in a specific site. All other activity between these two sites already have the mapping. A good scaling benefit. >> o Experiment with provider-independent assignment of EIDs > Any thoughts on what this would be? Either for the > experiment or for a full-blown solution later? That > is, what space would be allocating the EIDs from? > Would they be syntactically distinguishable from > regular addresses? I think they should be syntactically distinguishable from locator addresses (err, the same addresses we use today) for debugging purposes. A sniffer trace really needs to reveal what's going on for debugging purposes. That is why we didn't want to go with an address rewrite solution but a new-header/tunneling solution. I would say to start, to get IANA to give out to an EID registry a couple class As. Is 32 million EIDs too small? This would be a non-problem if the inner header was IPv6. Having said that IPv4 has way plenty of addresses if they were only used for locators. So maybe we only need the hosts to convert to IPv6 to get the bountiful EID space and keep the router network IPv4. ;-) But I do believe to get LISP to scale better, you have to allocate blocks in power-of-2 chunks so we can aggregate EID-prefixes. Not so much to scale table size but to reduce control message flow and EID- to-RLOC cache misses. >> ICMP EID-to-RLOC Reply messages are authoritative to the same >> extent >> DNS Replies are. LISP is no less secure than DNS and at this >> time we >> do not intend to add any additional security mechanisms to the >> proposal. >> > I am not sure the comparison to DNS is correct. Well many have said this. We are planning on having some sort of security mechanism for the -01 draft release. But don't expect much because we don't want lots of infrastructure change. I have been advised by various operators to go lightweight here. That is, no third-party participation to manage keys. > A different comparison would be to look at what > attackers in different locations (on path, off > path, peers) can do and whether there is something > that changes in this proposal. > > If Request - Reply is defined so that only the Reply > has an effect and that suitable Reply contents > cannot be guessed by off-path attackers, then I I think spoof-detection isn't that hard to solve, that is if we really ought to solve it. But validating that ETR-x is the one that has RLOC A and B for EID-prefix foo is what some say needs to be solved and is where the slippery slope begins. > think we have roughly what we already have > for Internet security: on-path attackers will be > able to cause problems, but there is some > weak protection against off-path attackers. > This is mostly good enough, I think. Noted. > But I suspect there are details that the draft > did not go into. For instance, wouldn't there > be a need for a router to tell its peer that > the router's own addresses have changed? How > would that be implemented with only Request and > Reply? There will be no unsolicited replies. There can't be because you have to track all active ITRs that have spoken to you. That clearly doesn't scale and for the most part, what we have proposed is a fairly stateless ETR and only a mapping cache based ITR. Big content providers have told me for client packets coming into their server hosts, they do not want to 1) do a EID-to-RLOC mapping for returning packets to clients and 2) don't want to hold a mapping cache entry for a long period of time. So they will swap RLOCs when they can (which means the client site will control the return path to some extent). >> 2. The default router is configured as an ITR. It prepends a >> LISP >> header to the packet, with one of it's RLOCs as the source IP >> address and uses the destination EID from the original packet >> header as the destination IP address. > How does the ITR know that it can use LISP > towards this destination? Is it syntactically > obvious from the destination EID, is it configured, > or is it dynamically learned? Definitely not configured or else k number of EID-prefixes would have to be configured, where k, in best case is the number of destination ASes. For starters, you can use either 1) a FIB miss or a 2) default route hit as signifying the destination is outside of your AS. Of course, you can have ACLs as exception lists and for policy but let's not do this later for prototyping. >> o Experiment with mobility to determine if both acceptable >> convergence and session survivability properties can be >> scalably >> implemented to support both individual device roaming and site >> service provider changes. >> > The draft does not have a lot of other text on mobility. > I suspect there are details to be worked out... for instance, > would this be able to provide a rendezvous function > for simultaneously moving hosts? And it seems to > preclude talking to legacy hosts while moving. Well we have to understand the convergence expectations for mobility. Of course when a host is moving and the ETR is swapping locators, the ETR doesn't care. For the ITR, it is the same case as the initialization sequence since the new ITR may not have an EID-to-RLOC mapping. But for now, that is all we want to say. > And here are also some editorial comments while > I'm at it: >> When a data packet triggers a Reply to be sent, the RLOC >> associated >> with the EID-prefix matched by the EID in the original packet >> destination IP address field will be returned. > Did you mean "the RLOCs associated ...."? Presumably there > must be multiple RLOCs per EID or EID prefix. Yes, thanks, I will fix. >> [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol >> (HIP) Architecture", RFC 4423, May 2006. >> > Why was this listed as a normative reference? Were you > using something from this RFC? No, just wanted to include references to other solutions. > Jari Thanks again, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Feb 04 10:57:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDjhT-0000NA-4c; Sun, 04 Feb 2007 10:54:43 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDjhS-0000MR-A7 for ram@iab.org; Sun, 04 Feb 2007 10:54:42 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDjhP-0006VL-MF for ram@iab.org; Sun, 04 Feb 2007 10:54:42 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id EE4CA198775; Sun, 4 Feb 2007 17:54:35 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 215671986AF; Sun, 4 Feb 2007 17:54:34 +0200 (EET) Message-ID: <45C601BA.8030800@piuha.net> Date: Sun, 04 Feb 2007 10:54:34 -0500 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: "Pekka Nikander (JO/LMF)" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc Cc: ram@iab.org Subject: [RAM] thoughts on draft-nikander-ram-generix-proxying-00.txt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Pekka, I read your draft. Overall, I agree with your main message here. I think we do need both network- and host based mechanisms for deployment reasons, and they are indeed not all that different from each other. Your draft helps us understand the possible approaches better. However, the devil is in the details and I'd really like to see some of this worked out in more detail. Some comments & questions below: > > In this document, we take the stance that in order to be > architecturally sound, any layer-injecting solution must eventually > be implemented by all hosts, at least in an conceptual sense. ... > XXX Elaborate. > Perhaps you could elaborate this a bit here on the list. Do you mean that it must be possible for the hosts to be in control? Or that it must be possible for us to reach a situation where the new system is in use by everyone? What do these things have to do with architectural soundness? > 5.1. Using locators at transport and IP layer > > This approach has received relatively little study. > > One fundamental problem is the need for TCP to resynchronise in the > case of locator change. That is, if the layer above detects a need Implementing this in a library has not received a lot of attention, true. But there are of course many applications that have been built with at least partial capabilities to deal with changing locators. > If the host has > multiple interfaces, each interface should be logically configured > with the same local IP address, since the goal is to have just one > identifier for each host, and all the proxies at the various local > paths must perform compatible rewriting. This seems non-trivial. How would the host know whether the interfaces are part of the same area served by the compatible proxies? How would the host select a particular outgoing interface for its packets? > From a logical point of view, this approach can be illustrating by > 'strething' the host stack to the new middle box. That is, we split > the host stack at the rewriting function (whereever it happens to > be), leave everything above at the host itself, and move everything > below to the proxy. This is illustrated in Figure XXX. Physically, > of course, the host stack remains complete and the 'stretching' is > performed by the local subnetwork; see Figure XXX. That you can do this is not very surprising, IPsec, for instance, works this way. But how easy and clean this is depends on where exactly the rewriting function is. In the IPsec case, for instance, you end up having fragmentation in two places in the stretched case whereas it was only needed once in host mode. I hope the proxies will be very simple, so requiring them to take on some transport functionality might not be such a great idea, for instance. > We now consider the > situation where the goal is to connect a completely 'new' host, one > that no longer has direct 'old' connectivity, to a predominantly > 'old' world. > > ... > > To provide connectivity from 'new' hosts to 'old' hosts, the proxy > must implement active DNS proxying. That is, when a 'new' host makes > a DNS query asking for the identity and locators for an 'old' host, > the proxy answers with a fabricated identity and its own locators. > Correspondingly, when an 'old' host makes a DNS query asking for the > IP addresses of a 'new' host, the proxy provides with its own IP > addresses. Right, but you made one big assumption above, namely that the new hosts are completely disconnected from the old Internet. If the identifier space is syntactically same as the current IP space (e.g. orchids) then new hosts should be able to use peer's address directly, similar to what NATs do currently. The new host's own address, however, is a different matter. > 6.5. Un-proxying in the 'in-the-network' approach > > In the same spirit but in the reverse fashion, the 'in-the-network' > or jack up approaches can be implemented within the host instead of > in a separate box. In this case, we 'squeeze' the local subnetwork > into the host itself, making it to physically disappear. Interestingly, in this case the host would perhaps have just one interface as far as the original IP stack is concerned, but multiple interfaces below the jack-up shim. The host would then be able to make multihoming decisions. > The easiest case is when the identifiers are fully routable, like > in SHIM6. In that case there are few limitations where and how > the proxies can be located at, as long as they are on the default > path between the 'old' and 'new' hosts. For example, each site > exist could be equipped with a SHIM6 proxy, knowledgeable about > all the other prefixes the site has, and being able to redirect > the traffic on demand. This is interesting. Is there a draft or more details about this? > 8. Security considerations > > > 9. Discussion Something missing here, obviously. I would be particularly interested in hearing what the details are for, say, HIP-like network-based implementation. If hosts are given true identifier space to work on, wouldn't that mean that they "own" the identifiers and associated public keys? How would this enable the proxy to perform operations on the identifiers, such as claiming that the identifier is now reachable at a new locator? Or is there some delegation involved? Or would the identifiers be "owned" by the proxy, and the hosts see merely local address space? > Respectively, 'network' based approaches grow from the assumption > that the hosts cannot be trusted (as, e.g., they may be compromised) > and therefore it is better for the network to provide the > functionality. I think we need to be a bit careful here. What we are talking about is functionality that affects how packets for a given host are delivered. Even when we implement everything in the network, the host is still left with an ability to, for instance, decide with who, when, and how much to communicate, what interface to use, what identifier to claim for itself. Is there a real difference in terms of vulnerabilities? Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Feb 04 17:59:34 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDqIb-0005gF-DB; Sun, 04 Feb 2007 17:57:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HDqIZ-0005ZK-Ni for ram@iab.org; Sun, 04 Feb 2007 17:57:27 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HDqIY-0005p1-DM for ram@iab.org; Sun, 04 Feb 2007 17:57:27 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 04 Feb 2007 14:57:24 -0800 X-IronPort-AV: i="4.13,279,1167638400"; d="scan'208"; a="108910473:sNHT42658047" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l14MvNoM028486; Sun, 4 Feb 2007 14:57:23 -0800 Received: from [10.32.245.158] (sjc-vpn-hwcore-601.cisco.com [10.21.154.89]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l14MvIGk001475; Sun, 4 Feb 2007 14:57:23 -0800 (PST) In-Reply-To: <45C1B205.6050905@zurich.ibm.com> References: <4E0BE885-C751-4F46-AC1B-1E1E0B971D5B@extremenetworks.com> <45C1B205.6050905@zurich.ibm.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8820ECA5-72E9-404A-B94C-1B84A6E0EEE3@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [RAM] Re: server referrals Date: Sun, 4 Feb 2007 15:31:29 -0500 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1273; t=1170629843; x=1171493843; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=oran@cisco.com; z=From:=20David=20R=20Oran=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20server=20referrals |Sender:=20; bh=hL77SCFaFOyjgab7empvc7RJrPmwoPvDeR3l+lF0xQM=; b=YA1FD+Y2q0DdFyH9nVwtNJs48KS75XQoPNOvdzYKeTIHbMF9vMnAo60ArAkEKkPS/mj07NC0 WFRCTN8SiunSuKMUln7HEHV0PQpOw1cyBtLOsTVuxfs9w+8ZjaAkbfMG; Authentication-Results: sj-dkim-2; header.From=oran@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: RJ Atkinson , ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Feb 1, 2007, at 4:25 AM, Brian E Carpenter wrote: > On 2007-01-31 16:32, RJ Atkinson wrote: >> Earlier Thomas Narten wrote: >>> IMO, this assertion needs to be shown to be true. >>> I suspect its very much not. >> Well, if one is looking to prove assertions, let us please start >> with proving the unsubstantiated assertion that server referrals >> necessarily are broken by moving to an ID/Locator split. > > Actually it might be exactly the opposite: referrals are widely > broken today by NATs and VPNs (which both cause addresses to > have a limited context of validity) whereas I assume that any loc/id > split will at least have the virtue of providing global ids. > > To put it another way, we should make this a requirement: ids > must be able to serve as 3rd party references. > I agree with this to the extent that such references have an assumed temporal scope - i.e. they can be assumed to be valid at the time of referral but not for an indefinite period thereafter. In this respect they differ from identifiers assumed to be temporally immutable like public keys or UUIDs. > Brian > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 06 19:04:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEaG0-0000dL-I2; Tue, 06 Feb 2007 19:01:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEaFz-0000aD-Ka for ram@iab.org; Tue, 06 Feb 2007 19:01:51 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEaFv-0003hB-8R for ram@iab.org; Tue, 06 Feb 2007 19:01:51 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l1701QAV028886; Tue, 6 Feb 2007 16:01:26 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l1701MQU028885; Tue, 6 Feb 2007 16:01:22 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 6 Feb 2007 16:01:22 -0800 From: David Meyer To: ram@iab.org Message-ID: <20070207000122.GC28785@1-4-5.net> Mime-Version: 1.0 User-Agent: Mutt/1.4.1i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-gpg-fingerprint: 2409 8B50 B389 A307 BA5C 2A16 3918 03D6 A099 D8A7 X-philosophy: "But that's not the way it feels" -- Jim Croce, Operator X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: gaurab@pch.net Subject: [RAM] "Future of Routing" Workshop at Apricot 2007 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1312082123==" Errors-To: ram-bounces@iab.org --===============1312082123== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="m51xatjYGsM+13rf" Content-Disposition: inline --m51xatjYGsM+13rf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Folks, =20 The Asia Pacific Internet Association (APIA) is hosting a 'Future of Routing' workshop at the next Asia Pacific Regional Internet Conference on Operational Technologies (see www.apricot2007.net for the general conference details; the workshop is being held on 26-27 Feb 2007).=20 =20 The goals of the workshop are twofold: it is intended to be both an educational forum (quite a bit is going on in this space), and to gather input from the Asia Pacific region on the ongoing discussions about the future of the Internet's Routing and Addressing system.=20 =20 Finally, the agenda is in draft form and should be published tomorrow. =20 Thanks, =20 --dmm, Gaurab, and Philip =20 =20 --m51xatjYGsM+13rf Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFFyRbSORgD1qCZ2KcRAlVsAJwNhcBkFOMBDbK2+fesy+3C0PC02wCdFcBE ZefIEcRfG7UrvbqXUV6NaG0= =rCs/ -----END PGP SIGNATURE----- --m51xatjYGsM+13rf-- --===============1312082123== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1312082123==-- From ram-bounces@iab.org Wed Feb 07 06:33:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEl2H-0005kN-GB; Wed, 07 Feb 2007 06:32:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEl2G-0005kC-LE for ram@iab.org; Wed, 07 Feb 2007 06:32:24 -0500 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEl2C-0006PU-3S for ram@iab.org; Wed, 07 Feb 2007 06:32:24 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l17BWJm0030670 for ; Wed, 7 Feb 2007 11:32:19 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l17BWJGD1855548 for ; Wed, 7 Feb 2007 12:32:19 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l17BWIKB004839 for ; Wed, 7 Feb 2007 12:32:18 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l17BWIiG004826 for ; Wed, 7 Feb 2007 12:32:18 +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 MAA47192 for ; Wed, 7 Feb 2007 12:32:17 +0100 Message-ID: <45C9B8C0.9070100@zurich.ibm.com> Date: Wed, 07 Feb 2007 12:32:16 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Subject: [RAM] draft-farinacci-lisp-00 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, Vince and Dave O, First, don't take this the wrong way, but I think your terminology is broken. To see what I mean, try the following substitutions: EID -> SLOC (site locator) RLOC -> GLOC (global locator) Why? Because in fact, as you describe things, the SLOC (EID) is a valid locator in the infrastructure of the end site, which might by the way be an international corporate network. The GLOC (RLOC) is a valid locator in the global Internet. I can take this a little further. We could also imagine a VLOC (VPN locator) which would apply on a VPN infrastructure, but would logically be at the same level as a GLOC. If you follow this logic and your mention of recursion, I think you end up with xLOC where x stands for the routing context in which the xLOC is used. You could certainly have a recursively encapsulated packet GLOC.VLOC.SLOC.payload, for example. Or alternatively you could say that in the case of a GLOC.SLOC.payload packet, the Internet is the default VPN. Apart from breaking your cute acronym, I don't think this changes anything in your proposal. But I'm a bit leery of using "ID/loc split" to describe what is actually a multi-level locator scheme. (Which BTW I think is a very good approach, and I've thought so since 1994.) I can also restore the acronym: Locators In Sequence Protocol, or Locators for Internet and Sites Protocol. Now for a few specific comments. > 2. Introduction ... > 1. Reduction of routing table size in the "default-free zone" (DFZ). > Use of a separate numbering space for RLOCs will allow them to be > assigned topologically (in today's Internet, RLOCs would be > assigned by providers at client network attachment points), > greatly improving aggregation and reducing the number of > globally-visible, routable prefixes. I think you probably mean "Containment" rather than "Reduction" in practice. Also you miss out what I think is an important point: containment of the number of BGP4 updates caused by edge prefixes. (If you don't contain those, I think you don't solve the most serious problem.) Also I don't notice any explicit mention of multihoming here. I think you need to be more clear how multihoming works with LISP. ... > Note that while the detailed protocol > specification and examples in this document assume IP version 4 > (IPv4), there is nothing in the design that precludes use of the same > techniques and mechanisms for IPv6. It should be possible for IPv4 > packets to use IPv6 RLOCs and for IPv6 EIDs to be mapped to IPv4 > RLOCs. I think that you'll generate more negative feeling by not typing in the IPv6 mapping than the saving in effort is worth :-) Also, I'm curious how this will relate to what's already being done in SOFTWIRE. > 4. Basic Overview > > One key concept of LISP is that end-systems (hosts) operate the same > way they do today. The IP addresses that hosts use for tracking > sockets, connections, and for sending and receiving packets do not > change. In LISP terminology, these IP addresses are called Endpoint > Identifiers (EIDs). > > Routers continue to forward packets based on IP destination > addresses. These addresses are referred to as Routing Locators > (RLOCs). Most routers along a path between two hosts will not > change; they continue to perform routing/forwarding lookups on > addresses (RLOCs) in the IP header. Another point to mention is that site infrastructure, from SOHO to large corporate, will continue to use "EIDs" as fully functional locators (which is why I think you are wrong to describe this as an ID/loc split). And that VPNs will continue to work largely as they do today. In fact, upper layers will just see TTLLAAs as they do today. (TTLLAA = thing that looks like an address). That's a shared feature with shim6 and an excellent property. > 4.1. Packet Flow Sequence ... > 4. The LISP header is stripped so that the packet can be forwarded > by the router control-plane. The router looks up the destination > EID in the router's EID-to-RLOC database (not the cache, but the > configured data structure of RLOCs). An ICMP EID-to-RLOC Mapping > message is originated by the egress router and is addressed to > the source RLOC from the LISP header of the original packet (this > is the ITR). The source RLOC in the IP header of the ICMP > message is one of the ETR's RLOCs (one of the RLOCs that is > embedded in the ICMP payload). What happens about lost ICMP packets, and how do you deal with ICMP filtering, which is pretty common? > 5. Tunneling Details Nit: "Type of Service" is called "Differentiated Services Field" since RFC 2474. Also, is there any nasty interaction with ECN? > 10. Security Considerations Well, I'd really want to see more of a threat analysis. Surely some of the attacks against shim6 would apply here too, unless you deem the routing infrastructure immune to subversion? Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 07 09:40:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnx7-00081d-Df; Wed, 07 Feb 2007 09:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnx7-00081W-0Y for ram@iab.org; Wed, 07 Feb 2007 09:39:17 -0500 Received: from elle.sprintlink.net ([199.0.234.34] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEnx5-0001qb-6a for ram@iab.org; Wed, 07 Feb 2007 09:39:16 -0500 Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id l17ETXt01666; Wed, 7 Feb 2007 09:29:33 -0500 (EST) Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id JAA16454; Wed, 7 Feb 2007 09:42:36 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Wed, 7 Feb 2007 09:42:36 -0500 (EST) From: Ted Seely X-X-Sender: To: David Meyer Subject: Re: [RAM] "Future of Routing" Workshop at Apricot 2007 In-Reply-To: <20070207000122.GC28785@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: gaurab@pch.net, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org any chance you can this tuesday? i don't arrive until late monday evening. -ted On Tue, 6 Feb 2007, David Meyer wrote: > Folks, > > The Asia Pacific Internet Association (APIA) is hosting a > 'Future of Routing' workshop at the next Asia Pacific > Regional Internet Conference on Operational Technologies > (see www.apricot2007.net for the general conference > details; the workshop is being held on 26-27 Feb 2007). > > The goals of the workshop are twofold: it is intended to > be both an educational forum (quite a bit is going on in > this space), and to gather input from the Asia Pacific > region on the ongoing discussions about the future of the > Internet's Routing and Addressing system. > > Finally, the agenda is in draft form and should be > published tomorrow. > > Thanks, > > --dmm, Gaurab, and Philip > > > > > Ted Seely Principal Network Design Engineer Internet Engineering - SprintLink (W) 703.689.6425 (M) 703.967.3289 AIM - wanpro00 Yahoo IM - tseely01 "can be maintained, upgraded, enhanced, and scaled without requiring service interruption" _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 07 09:40:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnwy-0007zN-26; Wed, 07 Feb 2007 09:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnww-0007yx-GF for ram@iab.org; Wed, 07 Feb 2007 09:39:06 -0500 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEnwt-0001hg-MV for ram@iab.org; Wed, 07 Feb 2007 09:39:06 -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 l17Ed21B199524 for ; Wed, 7 Feb 2007 14:39:02 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com From ram-bounces@iab.org Wed Feb 07 09:40:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnx7-00081d-Df; Wed, 07 Feb 2007 09:39:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnx7-00081W-0Y for ram@iab.org; Wed, 07 Feb 2007 09:39:17 -0500 Received: from elle.sprintlink.net ([199.0.234.34] helo=elle.res.sprintlink.net) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEnx5-0001qb-6a for ram@iab.org; Wed, 07 Feb 2007 09:39:16 -0500 Received: from iscserv1.res.sprintlink.net (iscserv1.res.sprintlink.net [199.0.237.253]) by elle.res.sprintlink.net (8.11.6+Sun/8.11.6) with ESMTP id l17ETXt01666; Wed, 7 Feb 2007 09:29:33 -0500 (EST) Received: from localhost (tseely@localhost) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id JAA16454; Wed, 7 Feb 2007 09:42:36 -0500 (EST) X-Authentication-Warning: iscserv1.res.sprintlink.net: tseely owned process doing -bs Date: Wed, 7 Feb 2007 09:42:36 -0500 (EST) From: Ted Seely X-X-Sender: To: David Meyer Subject: Re: [RAM] "Future of Routing" Workshop at Apricot 2007 In-Reply-To: <20070207000122.GC28785@1-4-5.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: gaurab@pch.net, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org any chance you can this tuesday? i don't arrive until late monday evening. -ted On Tue, 6 Feb 2007, David Meyer wrote: > Folks, > > The Asia Pacific Internet Association (APIA) is hosting a > 'Future of Routing' workshop at the next Asia Pacific > Regional Internet Conference on Operational Technologies > (see www.apricot2007.net for the general conference > details; the workshop is being held on 26-27 Feb 2007). > > The goals of the workshop are twofold: it is intended to > be both an educational forum (quite a bit is going on in > this space), and to gather input from the Asia Pacific > region on the ongoing discussions about the future of the > Internet's Routing and Addressing system. > > Finally, the agenda is in draft form and should be > published tomorrow. > > Thanks, > > --dmm, Gaurab, and Philip > > > > > Ted Seely Principal Network Design Engineer Internet Engineering - SprintLink (W) 703.689.6425 (M) 703.967.3289 AIM - wanpro00 Yahoo IM - tseely01 "can be maintained, upgraded, enhanced, and scaled without requiring service interruption" _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 07 09:40:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnwy-0007zN-26; Wed, 07 Feb 2007 09:39:08 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HEnww-0007yx-GF for ram@iab.org; Wed, 07 Feb 2007 09:39:06 -0500 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HEnwt-0001hg-MV for ram@iab.org; Wed, 07 Feb 2007 09:39:06 -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 l17Ed21B199524 for ; Wed, 7 Feb 2007 14:39:02 GMT Received: from d12av04.megacenter.de.ibm.com (d12av04.megacenter.de.ibm.com [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l17Ed21m1859658 for ; Wed, 7 Feb 2007 15:39:02 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l17Ed2gQ022135 for ; Wed, 7 Feb 2007 15:39:02 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l17Ed1LM022122; Wed, 7 Feb 2007 15:39:02 +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 PAA313680; Wed, 7 Feb 2007 15:39:00 +0100 Message-ID: <45C9E483.7000900@zurich.ibm.com> Date: Wed, 07 Feb 2007 15:38:59 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Fergie Subject: Re: [RAM] Re: Routing & Addressing -- activities (BOF) References: <20070123.223251.19107.2004754@webmail50.lax.untd.com> In-Reply-To: <20070123.223251.19107.2004754@webmail50.lax.untd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-24 07:32, Fergie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- Brian Carpenter wrote: > >> As part of the routing and addressing activities, a BOF is planned >> during IETF 68, as a plenary activity (day and time to be >> announced later). This will be tracked in the BOF wiki at > http://www1.tools.ietf.org/bof/trac/wiki >> >> Details so far: >> >> * ROAP >> o ROuting and Addressing Problem BOF >> o Joint with Internet Area; will be a plenary session >> o Status: preliminary discussions >> o Background: RAWS report >> o Responsible ADs: Ross Callon, Mark Townsley >> >> Ross and Mark will be collecting proposals for the goals >> and content of the BOF. >> > > Has there been any updates to report on this? :-) I'm not sure anyone answered this. The best I can say right now is to keep an eye on the URL above where the latest info we have is to be found. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram [9.149.165.229]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l17Ed21m1859658 for ; Wed, 7 Feb 2007 15:39:02 +0100 Received: from d12av04.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l17Ed2gQ022135 for ; Wed, 7 Feb 2007 15:39:02 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av04.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l17Ed1LM022122; Wed, 7 Feb 2007 15:39:02 +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 PAA313680; Wed, 7 Feb 2007 15:39:00 +0100 Message-ID: <45C9E483.7000900@zurich.ibm.com> Date: Wed, 07 Feb 2007 15:38:59 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Fergie Subject: Re: [RAM] Re: Routing & Addressing -- activities (BOF) References: <20070123.223251.19107.2004754@webmail50.lax.untd.com> In-Reply-To: <20070123.223251.19107.2004754@webmail50.lax.untd.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-01-24 07:32, Fergie wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -- Brian Carpenter wrote: > >> As part of the routing and addressing activities, a BOF is planned >> during IETF 68, as a plenary activity (day and time to be >> announced later). This will be tracked in the BOF wiki at > http://www1.tools.ietf.org/bof/trac/wiki >> >> Details so far: >> >> * ROAP >> o ROuting and Addressing Problem BOF >> o Joint with Internet Area; will be a plenary session >> o Status: preliminary discussions >> o Background: RAWS report >> o Responsible ADs: Ross Callon, Mark Townsley >> >> Ross and Mark will be collecting proposals for the goals >> and content of the BOF. >> > > Has there been any updates to report on this? :-) I'm not sure anyone answered this. The best I can say right now is to keep an eye on the URL above where the latest info we have is to be found. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 08 02:45:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF3vk-0000cg-Sz; Thu, 08 Feb 2007 02:42:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF3vk-0000cb-9g for ram@iab.org; Thu, 08 Feb 2007 02:42:56 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF3vj-00007X-Jr for ram@iab.org; Thu, 08 Feb 2007 02:42:56 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 354FD212D23; Thu, 8 Feb 2007 09:42:45 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 575A7212D22; Thu, 8 Feb 2007 09:42:44 +0200 (EET) In-Reply-To: <45C601BA.8030800@piuha.net> References: <45C601BA.8030800@piuha.net> 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: Pekka Nikander Subject: Re: [RAM] thoughts on draft-nikander-ram-generix-proxying-00.txt Date: Thu, 8 Feb 2007 09:42:40 +0200 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bcd240e64c427d3d3617cfc704e7fd7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Jari, Thanks for taking the effort to read the draft, even in its early form. > Some comments & questions below: > >> >> In this document, we take the stance that in order to be >> architecturally sound, any layer-injecting solution must >> eventually >> be implemented by all hosts, at least in an conceptual sense. ... >> XXX Elaborate. >> > Perhaps you could elaborate this a bit here on the list. > Do you mean that it must be possible for the hosts to be > in control? Or that it must be possible for us to reach > a situation where the new system is in use by everyone? > What do these things have to do with architectural > soundness? Hmm. I may not have completely cleared my mind here yet, so take the following with a grain of salt. My thinking starts from the desirability of having identifiers for end-points, i.e., in the most typical case, nodes. In my thinking, these identifiers should be location and interface independent. So, with "architectural soundness" I intend to refer to a situation where this has been achieved, and where the hosts indeed are, or at least can be, in primary control of their identity, independent of their network attachment. This comes from the standpoint of the draft, that implementing identifier/locator split is _the_ approach. Now, there is certainly another possible approach to the routing scalability problem: hierarchy or recursion. That is, you keep the TTLLAA that the application see as locators, but only as locators that have local locality. I haven't read the LISP draft, but based on Brian's comments on it, it seems to go to that direction. Hence, the main message of the generix draft may not apply to it. >> 5.1. Using locators at transport and IP layer >> >> This approach has received relatively little study. >> >> One fundamental problem is the need for TCP to resynchronise in >> the >> case of locator change. That is, if the layer above detects a >> need > > Implementing this in a library has not received a lot of > attention, true. But there are of course many applications that > have been built with at least partial capabilities to deal with > changing locators. Indeed. But they all must make for the case that they may not know whether the last data sent on the previous TCP connection reached the destination or not. >> If the host has >> multiple interfaces, each interface should be logically configured >> with the same local IP address, since the goal is to have just one >> identifier for each host, and all the proxies at the various local >> paths must perform compatible rewriting. > > This seems non-trivial. How would the host know whether > the interfaces are part of the same area served by the > compatible proxies? How would the host select a particular > outgoing interface for its packets? The text clearly needs here some clarification. But you are right, that is hard in the generic case. However, what I had in mind was a legacy host that assumedly sits in a corporate network. In that case I don't think it unreasonable to expect compatible proxies. I agree that if you consider a multi- interface mobile host (such as a laptop) the expectation would be unreasonable. However, I fail to see how you could fit such a host, with a legacy stack, to the "new" world anyway. That is, in such a case I cannot see how you can provide the upper layer protocols with a unique identifier without changing the stack. Maybe there is a way, but it just evades me. >> From a logical point of view, this approach can be illustrating by >> 'strething' the host stack to the new middle box. That is, we >> split >> the host stack at the rewriting function (whereever it happens to >> be), leave everything above at the host itself, and move >> everything >> below to the proxy. This is illustrated in Figure XXX. >> Physically, >> of course, the host stack remains complete and the 'stretching' is >> performed by the local subnetwork; see Figure XXX. > > That you can do this is not very surprising, IPsec, for instance, > works this way. But how easy and clean this is depends > on where exactly the rewriting function is. In the IPsec > case, for instance, you end up having fragmentation in > two places in the stretched case whereas it was only > needed once in host mode. I hope the proxies will > be very simple, so requiring them to take on some > transport functionality might not be such a great > idea, for instance. I agree. >> We now consider the >> situation where the goal is to connect a completely 'new' host, >> one >> that no longer has direct 'old' connectivity, to a predominantly >> 'old' world. >> >> ... >> >> To provide connectivity from 'new' hosts to 'old' hosts, the proxy >> must implement active DNS proxying. That is, when a 'new' host >> makes >> a DNS query asking for the identity and locators for an 'old' >> host, >> the proxy answers with a fabricated identity and its own locators. >> Correspondingly, when an 'old' host makes a DNS query asking >> for the >> IP addresses of a 'new' host, the proxy provides with its own IP >> addresses. > > Right, but you made one big assumption above, namely > that the new hosts are completely disconnected from the > old Internet. Indeed. > If the identifier space is syntactically same > as the current IP space (e.g. orchids) then new hosts > should be able to use peer's address directly, similar to > what NATs do currently. The new host's own address, > however, is a different matter. Yes. That case is covered later, in the "Stretching the wire" section. >> 6.5. Un-proxying in the 'in-the-network' approach >> >> In the same spirit but in the reverse fashion, the 'in-the- >> network' >> or jack up approaches can be implemented within the host >> instead of >> in a separate box. In this case, we 'squeeze' the local >> subnetwork >> into the host itself, making it to physically disappear. > > Interestingly, in this case the host would perhaps have > just one interface as far as the original IP stack is concerned, > but multiple interfaces below the jack-up shim. The host > would then be able to make multihoming decisions. Indeed. >> The easiest case is when the identifiers are fully routable, >> like >> in SHIM6. In that case there are few limitations where and how >> the proxies can be located at, as long as they are on the >> default >> path between the 'old' and 'new' hosts. For example, each site >> exist could be equipped with a SHIM6 proxy, knowledgeable about >> all the other prefixes the site has, and being able to redirect >> the traffic on demand. > > This is interesting. Is there a draft or more details about this? I am not aware of any draft in that space. However, to me, the only more complex problem seems to be security. But maybe I just fail to see some routing or co-ordination problems there. In the SHIM6 case security can be taken care of with CGAs and explicit public key based delegation. >> 8. Security considerations >> >> 9. Discussion > > Something missing here, obviously. Yep. :-) I indicated that in the beginning of the draft. > I would be particularly interested in hearing what the > details are for, say, HIP-like network-based implementation. As you might remember, there is a spec for the 3GPP HIP proxying case from the work we did two years ago, but that's not in an I-D format. The same idea can be easily extended to other networks. I guess Petri or someone could convert and generalise the text, if needed. > If hosts are given true identifier space to work on, wouldn't > that mean that they "own" the identifiers and associated > public keys? > How would this enable the proxy to perform > operations on the identifiers, such as claiming that the > identifier is now reachable at a new locator? Or is there > some delegation involved? Or would the identifiers be > "owned" by the proxy, and the hosts see merely local > address space? Both are possible, depending on your trust assumptions. You can arrange it in such a way that the "proxy" "owns" the identifiers, and assigns them (e.g. via DHCP or PPP) to the hosts. That was the method we used . In the case the host "owns" the identifier, you indeed need delegation. >> Respectively, 'network' based approaches grow from the assumption >> that the hosts cannot be trusted (as, e.g., they may be >> compromised) >> and therefore it is better for the network to provide the >> functionality. > > I think we need to be a bit careful here. What we are talking > about is functionality that affects how packets for a given > host are delivered. Even when we implement everything > in the network, the host is still left with an ability to, for > instance, decide with who, when, and how much to > communicate, what interface to use, what identifier to > claim for itself. Is there a real difference in terms of > vulnerabilities? I don't see any real difference in the vulnerabilities, but a) I haven't done any proper analysis and b) there are other people that see (or at least think they see) there a difference. --Pekka _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 08 08:05:29 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8wp-0002AE-JM; Thu, 08 Feb 2007 08:04:23 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF8wo-00026a-Dm for ram@iab.org; Thu, 08 Feb 2007 08:04:22 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF8wj-0000wX-3v for ram@iab.org; Thu, 08 Feb 2007 08:04:22 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 212AF3407B; Thu, 8 Feb 2007 08:04:40 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 08:04:12 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Thu, 8 Feb 2007 08:04:10 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> In-Reply-To: <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: thoughts on draft-farinacci-lisp-00 Thread-index: AcdHCf3aB8282VoLQ/2BAadwt1vdRwEKsS2A References: <45BE2530.2050600@piuha.net> <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> From: "Bound, Jim" To: "Dino Farinacci" , "Jari Arkko" X-OriginalArrivalTime: 08 Feb 2007 13:04:12.0754 (UTC) FILETIME=[A102FB20:01C74B81] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino, I like very much this technology approach using LISP to resolve RAM issues. Great job by you, Dave, and Vince and contribution to the IETF. Suggest you target stable draft for July Chicago meeting Prague is far to soon. Then shift right other time frames. I hope we can move in this direction and it left doors open for ongoing and future work esp. for end-to-end. =20 A suggestion is make the draft IP version agnostic and yes this will work with IPv6 on first two general reads. I am willing to help you do this if you want the help. I also believe it is transparent to Mobile IP work and for me that problem is solved and LISP does not preclude using what we have today, but will make it more efficient (hand waving here for now yes). This architecture assumes PI space for all sites is globally in the DNS. Do you agree with that assumption? A question will there be any IPR claims on the LISP architecture? =20 >LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC > mappings; such routing is via a separate topology. Then from EID definition: >LISP uses PI blocks for EIDs; such EIDs MUST > NOT be used as a LISP RLOCs.=20 Does the above mean EIDs cannot use PA's? I believe there are cases within LISP where optimizations are necessary to reduce the LISP processing at the edge and tunnel processing where the source packet is capable of simply passing through the LISP site topology. I am sure you know the mission critical use cases here so I will not note them for now.=20 Specifically: >o End-systems (hosts) only know about EIDs. I am fine with this but then there may be cases where end-system becomes intermediate node or something to that effect to address the use cases for optimizations I reference above.=20 This could produce a new set of new type of edge boxes/software in the market too should we consider those consequences, as discussed under ITR terminology. >Some of the design goals of this proposal include: I think we need to add multi-homing to this set of goals too. And from PA defintion below: >Traditionally, IP multihoming has been implemented by each multi-homed site acquiring=20 >its own, globally-visible prefix. LISP uses only topologically-assigned and=20 >aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable=20 >practice. I think the above will assist with the multi-homing problem and suggest we need section in the draft why that is true. >Egress Tunnel Router (ETR): a router that accepts an IP packet > where destination address in the "outer" IP header is one of its > own RLOCs. The router strips the "outer" header and forwards the > packet based on the next IP header found. In general, an ETR > receives LISP-encapsulated IP packets from the Internet on one > side and sends decapsulated IP packets to site end-systems on the > other side. Assuming here below the ETR is the last router within a site to forward a packet to the destination over an Intranet or Internet? Does not the above assume or state the ETR is sending the End Systems IP packet which implies the End System IP header prior to ITR knew the RLOC? Seems confusing? Section 4.1 Packet Flow Sequence #3 did not help me? LISP does not alter the orginal end-systems IP header is my read of the spec? >o EIDs are not expected to be usable for end-to-end communication in > the absence of an EID-to-RLOC mapping operation. But, the end-system should be able to encrypt all but the IP header (with IPv6 the options are in the clear too) and pass through the ITR and ETR. In addtion this gets to the required optimizations above in certain cases. >o EIDs may also be structured (subnetted) in a manner suitable for > local routing within an autonomous system. Suggest change to "EID can also be ...." remove the connotation of "MAY" above. I need to spend more time with sections 6,7,8,9,10. Probably will send mail if required for each of them individually. Thanks /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 08 08:19:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9BM-0001XP-OQ; Thu, 08 Feb 2007 08:19:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9BL-0001XI-1J for ram@iab.org; Thu, 08 Feb 2007 08:19:23 -0500 Received: from usaga01-in.huawei.com ([206.16.17.211]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF9BD-0005xb-JP for ram@iab.org; Thu, 08 Feb 2007 08:19:23 -0500 Received: from huawei.com (usaga04-in [172.18.9.16]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0JD5000F3BO2ML@usaga04-in.huawei.com> for ram@iab.org; Thu, 08 Feb 2007 07:19:15 -0600 (CST) Received: from s73602 (cpe-72-190-0-23.tx.res.rr.com [72.190.0.23]) by usaga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0JD500A2ZBNXCR@usaga04-in.huawei.com> for ram@iab.org; Thu, 08 Feb 2007 07:19:14 -0600 (CST) Date: Thu, 08 Feb 2007 07:19:04 -0600 From: Spencer Dawkins Subject: Re: [RAM] thoughts on draft-nikander-ram-generix-proxying-00.txt To: ram@iab.org Message-id: <00d901c74b83$b5ca6e10$6501a8c0@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2962 X-Mailer: Microsoft Outlook Express 6.00.2900.2869 Content-type: text/plain; format=flowed; charset=iso-8859-1; reply-type=response Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <45C601BA.8030800@piuha.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, Pekka, I may be slightly confused here, but I'm seeing either imprecise words or an oncoming train, so I need to ask... >>> 5.1. Using locators at transport and IP layer >>> >>> This approach has received relatively little study. >>> >>> One fundamental problem is the need for TCP to resynchronise in the >>> case of locator change. That is, if the layer above detects a need >> >> Implementing this in a library has not received a lot of >> attention, true. But there are of course many applications that >> have been built with at least partial capabilities to deal with >> changing locators. > > Indeed. But they all must make for the case that they may not know > whether the last data sent on the previous TCP connection reached the > destination or not. Umm, for all values of id/loc discussion I've been involved with, there might be a previous TCP PATH, that is now changing, but there is no previous TCP CONNECTION. If this discussion goes in a direction where there is a different TCP connection, that's not good. The idea behind SHIM6 was that the TCP might see amazing changes in path characteristics, and might even have to do what TCP does anyway (discard duplicate packets, process out-of-order packets, and request retransmission of packets that don't seem to be making it to the far end, for whatever reason), but there would not be another SYN-SyN-ACK-ACK exchange. The idea was that the application using this connection would be either unaware of a change in path characteristics (most TCP-based applications would be), or at most mildly irritated that the path characteristics changed (but they are changing because there's no choice). If there's a new TCP connection, we can do that today. The idea as I understood it was to keep path-change complexity in TCP, and not in the applications using TCP. I'm probably overreacting, but I've spent way too many years talking to people who went through all kinds of contortions to make sure that "all the packets in-flight at cellular handover time are also handed off to the new path", etc. Given that we can't be perfect, the endpoints have to handle these problems anyway, and letting TCP do what TCP will do anyway is a lot easier than figuring out what packets actually got there on the other path, given that we can be changing networks, and changing link technologies (WiFi to GPRS being a classic example). Like TCP itself, I'll shut up now, and let the network-layer guys go back to doing network-layer stuff :-) Thanks, Spencer _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 08 08:45:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9ai-0000D9-5r; Thu, 08 Feb 2007 08:45:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HF9ag-0000D3-Ie for ram@iab.org; Thu, 08 Feb 2007 08:45:34 -0500 Received: from imo-m27.mx.aol.com ([64.12.137.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HF9ad-0004H0-62 for ram@iab.org; Thu, 08 Feb 2007 08:45:34 -0500 Received: from HeinerHummel@aol.com by imo-m27.mx.aol.com (mail_out_v38_r7.6.) id w.d2a.6e633e5 (29673); Thu, 8 Feb 2007 08:45:19 -0500 (EST) From: HeinerHummel@aol.com Message-ID: Date: Thu, 8 Feb 2007 08:45:16 EST Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 To: Jim.Bound@hp.com, dino@cisco.com, jari.arkko@piuha.net MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.7 (/) X-Scan-Signature: a4e5f67c5e230eddf754446d1a2201a4 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0041605144==" Errors-To: ram-bounces@iab.org --===============0041605144== Content-Type: multipart/alternative; boundary="-----------------------------1170942316" -------------------------------1170942316 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 And let me add another favoring aspect: The ETR would also be a perfect fit for being a CTR (cascade tree router) b= y=20 which DDoS attacks could be outsmarted and become ineffective as I pointed =20 out by some prevous email (to arch-d I think). =20 Heiner =20 In einer eMail vom 08.02.2007 14:05:28 Westeurop=E4ische Normalzeit schreibt= =20 Jim.Bound@hp.com: Dino, I like very much this technology approach using LISP to resolve RAM issues. Great job by you, Dave, and Vince and contribution to the IETF. Suggest you target stable draft for July Chicago meeting Prague is far to soon. Then shift right other time frames. I hope we can move in this direction and it left doors open for ongoing and future work esp. for end-to-end. =20 A suggestion is make the draft IP version agnostic and yes this will work with IPv6 on first two general reads. I am willing to help you do this if you want the help. I also believe it is transparent to Mobile IP work and for me that problem is solved and LISP does not preclude using what we have today, but will make it more efficient (hand waving here for now yes). This architecture assumes PI space for all sites is globally in the DNS. Do you agree with that assumption? A question will there be any IPR claims on the LISP architecture? >LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC > mappings; such routing is via a separate topology. Then from EID definition: >LISP uses PI blocks for EIDs; such EIDs MUST > NOT be used as a LISP RLOCs.=20 Does the above mean EIDs cannot use PA's? I believe there are cases within LISP where optimizations are necessary to reduce the LISP processing at the edge and tunnel processing where the source packet is capable of simply passing through the LISP site topology. I am sure you know the mission critical use cases here so I will not note them for now. =20 Specifically: >o End-systems (hosts) only know about EIDs. I am fine with this but then there may be cases where end-system becomes intermediate node or something to that effect to address the use cases for optimizations I reference above.=20 This could produce a new set of new type of edge boxes/software in the market too should we consider those consequences, as discussed under ITR terminology. >Some of the design goals of this proposal include: I think we need to add multi-homing to this set of goals too. And from PA defintion below: >Traditionally, IP multihoming has been implemented by each multi-homed site acquiring=20 >its own, globally-visible prefix. LISP uses only topologically-assigned and=20 >aggregatable address blocks for RLOCs, eliminating this demonstrably non-scalable =20 >practice. I think the above will assist with the multi-homing problem and suggest we need section in the draft why that is true. >Egress Tunnel Router (ETR): a router that accepts an IP packet > where destination address in the "outer" IP header is one of its > own RLOCs. The router strips the "outer" header and forwards the > packet based on the next IP header found. In general, an ETR > receives LISP-encapsulated IP packets from the Internet on one > side and sends decapsulated IP packets to site end-systems on the > other side. Assuming here below the ETR is the last router within a site to forward a packet to the destination over an Intranet or Internet? Does not the above assume or state the ETR is sending the End Systems IP packet which implies the End System IP header prior to ITR knew the RLOC? Seems confusing? Section 4.1 Packet Flow Sequence #3 did not help me? LISP does not alter the orginal end-systems IP header is my read of the spec? >o EIDs are not expected to be usable for end-to-end communication in > the absence of an EID-to-RLOC mapping operation. But, the end-system should be able to encrypt all but the IP header (with IPv6 the options are in the clear too) and pass through the ITR and ETR. In addtion this gets to the required optimizations above in certain cases. >o EIDs may also be structured (subnetted) in a manner suitable for > local routing within an autonomous system. Suggest change to "EID can also be ...." remove the connotation of "MAY" above. I need to spend more time with sections 6,7,8,9,10. Probably will send mail if required for each of them individually. Thanks /jim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1170942316 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
And let me add another favoring aspect:
The ETR would also be a perfect fit for being a CTR (cascade tree route= r)=20 by which DDoS attacks could be outsmarted and become ineffective as I pointe= d=20 out by some prevous email (to arch-d I think).
 
Heiner
 
In einer eMail vom 08.02.2007 14:05:28 Westeurop=E4ische Normalzeit sch= reibt=20 Jim.Bound@hp.com:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>Dino,

I like very much this technology approach using LISP= to=20 resolve RAM
issues.  Great job by you, Dave, and Vince and=20 contribution to the IETF.
Suggest you target stable draft for July Chic= ago=20 meeting Prague is far
to soon.  Then shift right other time=20 frames.

I hope we can move in this direction and it left doors open= for=20 ongoing
and future work esp. for end-to-end. 

A suggestion= is=20 make the draft IP version agnostic and yes this will
work with IPv6 on=20 first two general reads.  I am willing to help you do
this if you=20= want=20 the help.

I also believe it is transparent to Mobile IP work and fo= r me=20 that
problem is solved and LISP does not preclude using what we have=20 today,
but will make it more efficient (hand waving here for now=20 yes).

This architecture assumes PI space for all sites is globally=20= in=20 the DNS.
Do you agree with that assumption?

A question will ther= e be=20 any IPR claims on the LISP architecture?


>LISP 1.5:  wh= ere=20 EIDs are routable for bootstrapping EID-to-RLOC
>     = ;=20 mappings; such routing is via a separate topology.

Then from EID=20 definition:

>LISP uses PI blocks for EIDs; such EIDs=20 MUST
>      NOT be used as a LISP RLOCs.

Does= the=20 above mean EIDs cannot use PA's?

I believe there are cases within L= ISP=20 where optimizations are necessary
to reduce the LISP processing at the=20= edge=20 and tunnel processing where
the source packet is capable of simply pass= ing=20 through the LISP site
topology.  I am sure you know the mission=20 critical use cases here so I
will not note them for now.=20

Specifically:

>o  End-systems (hosts) only know abo= ut=20 EIDs.

I am fine with this but then there may be cases where end-sys= tem=20 becomes
intermediate node or something to that effect to address the us= e=20 cases
for optimizations I reference above.

This could produce a= new=20 set of new type of edge boxes/software in the
market too should we cons= ider=20 those consequences, as discussed under ITR
terminology.

>Some= of=20 the design goals of this proposal include:

I think we need to add=20 multi-homing to this set of goals too.

And from PA defintion=20 below:

>Traditionally, IP multihoming has been implemented by ea= ch=20 multi-homed
site acquiring
>its own, globally-visible prefix.&nb= sp;=20 LISP uses only
topologically-assigned and
>aggregatable address=20 blocks for RLOCs, eliminating this demonstrably
non-scalable=20
>practice.

I think the above will assist with the multi-homi= ng=20 problem and suggest
we need section in the draft why that is=20 true.

>Egress Tunnel Router (ETR):   a router that acc= epts=20 an IP packet
>     where destination address in the=20 "outer" IP header is one of its
>     own RLOCs. = ;=20 The router strips the "outer" header and forwards the
> =20    packet based on the next IP header found.  In general, a= n=20 ETR
>    receives LISP-encapsulated IP packets from the=20 Internet on one
>   side and sends decapsulated IP packets= to=20 site end-systems on the
> other side.

Assuming here below the= ETR=20 is the last router within a site to forward
a packet to the destination= =20 over an Intranet or Internet?

Does not the above assume or state th= e=20 ETR is sending the End Systems IP
packet which implies the End System I= P=20 header prior to ITR knew the
RLOC?   Seems=20 confusing?

Section 4.1 Packet Flow Sequence #3 did not help=20 me?

LISP does not alter the orginal end-systems IP header is my rea= d of=20 the
spec?

>o  EIDs are not expected to be usable for=20 end-to-end communication in
>      the absence of an=20 EID-to-RLOC mapping operation.

But, the end-system should be able t= o=20 encrypt all but the IP header
(with IPv6 the options are in the clear t= oo)=20 and pass through the ITR
and ETR.  In addtion this gets to the=20 required optimizations above in
certain cases.

>o  EIDs=20= may=20 also be structured (subnetted) in a manner suitable for
>  &nbs= p;=20   local routing within an autonomous system.

Suggest change to= =20 "EID can also be ...." remove the connotation of "MAY"
above.

I=20= need=20 to spend more time with sections 6,7,8,9,10.  Probably will send
m= ail=20 if required for each of them=20 individually.

Thanks
/jim

_______________________________= ________________
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
-------------------------------1170942316-- --===============0041605144== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============0041605144==-- From ram-bounces@iab.org Thu Feb 08 11:07:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBnI-0000Va-1w; Thu, 08 Feb 2007 11:06:44 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFBnH-0000Rx-Be for ram@iab.org; Thu, 08 Feb 2007 11:06:43 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFBnF-0006Zs-33 for ram@iab.org; Thu, 08 Feb 2007 11:06:43 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 213BE198776; Thu, 8 Feb 2007 18:06:24 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id CA98B1986AF; Thu, 8 Feb 2007 18:06:23 +0200 (EET) Message-ID: <45CB4A70.2060005@piuha.net> Date: Thu, 08 Feb 2007 18:06:08 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Spencer Dawkins Subject: Re: [RAM] thoughts on draft-nikander-ram-generix-proxying-00.txt References: <45C601BA.8030800@piuha.net> <00d901c74b83$b5ca6e10$6501a8c0@china.huawei.com> In-Reply-To: <00d901c74b83$b5ca6e10$6501a8c0@china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Spencer, Pekka and I were merely making the observation that there exists a body of applications that do these kinds of things -- not making any statement about how desirable that state of affairs is. I agree with your analysis of the issues. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 08 14:03:17 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFEWY-0006vi-CZ; Thu, 08 Feb 2007 14:01:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HFEWW-0006tG-Qy for ram@ietf.org; Thu, 08 Feb 2007 14:01:36 -0500 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HFEWP-0008VZ-27 for ram@ietf.org; Thu, 08 Feb 2007 14:01:36 -0500 Received: from [63.105.122.7] (account marshall_eubanks HELO [IPv6:::1]) by multicasttech.com (CommuniGate Pro SMTP 3.4.8) with ESMTP-TLS id 6171515 for ram@ietf.org; Thu, 08 Feb 2007 14:01:26 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@ietf.org From: Marshall Eubanks Date: Thu, 8 Feb 2007 14:01:25 -0500 X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Subject: [RAM] Some Relevant Presentations at the recent NANOG X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Here is a list of presentations from this week's meeting that I think might be relevant to this effort. In each case, it is title, followed by html abstract followed by presentation(s). Pushing the FIB limits, perspectives on pressures confronting modern routers. http://www.nanog.org/mtg-0702/jaeggli.html http://www.nanog.org/mtg-0702/presentations/fib-editorial.pdf http://www.nanog.org/mtg-0702/presentations/fib-hankins.pdf http://www.nanog.org/mtg-0702/presentations/fib-desilva.pdf http://www.nanog.org/mtg-0702/presentations/fib-ryan.pdf http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf (2 million routes!) http://www.nanog.org/mtg-0702/presentations/fib-atkinson.pdf Abstract: R-BGP: Ensuring Connectivity During BGP Convergence http://www.nanog.org/mtg-0702/kushman.html http://www.nanog.org/mtg-0702/presentations/Kushman.pdf Abstract: Introduction to Fast Convergence with Bidirectional Forwarding Detection (BFD) http://www.nanog.org/mtg-0702/akhter.html http://www.nanog.org/mtg-0702/presentations/akhter.pdf Regards Marshall Eubanks _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Feb 10 17:59:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG1AG-0002BO-Qj; Sat, 10 Feb 2007 17:57:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG1AE-0002BA-Mb for ram@iab.org; Sat, 10 Feb 2007 17:57:50 -0500 Received: from tayrelbas01.tay.hp.com ([161.114.80.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG1AA-0000j9-7D for ram@iab.org; Sat, 10 Feb 2007 17:57:50 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas01.tay.hp.com (Postfix) with ESMTP id 97E323404B; Sat, 10 Feb 2007 17:57:45 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 17:57:42 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sat, 10 Feb 2007 17:57:39 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0154FC01@tayexc14.americas.cpqcorp.net> In-Reply-To: <3B8DEB5C-B4BE-48FA-9A23-66B998640A8F@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: thoughts on draft-farinacci-lisp-00 Thread-index: AcdNYrkrNgF3L48OThSzr/uO8M1VGwAAipJQ References: <45BE2530.2050600@piuha.net> <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> <3B8DEB5C-B4BE-48FA-9A23-66B998640A8F@cisco.com> From: "Bound, Jim" To: "Dino Farinacci" X-OriginalArrivalTime: 10 Feb 2007 22:57:42.0026 (UTC) FILETIME=[DE9E2EA0:01C74D66] X-Spam-Score: 0.0 (/) X-Scan-Signature: 410b68b37343617c6913e76d02180b14 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, All set but provide clarifications and some stuff I was just missing the point and thanks for clearing me up. I think this is pretty awesome idea and implementation suggestion too. Will review other sections I noted to see if I can provide worthwhile input. Some responses in line.=20 > > Suggest you target stable draft for July Chicago meeting=20 > Prague is far=20 > > to soon. Then shift right other time frames. >=20 > Well my personal plan was to have a prototype available for=20 > people to play with. So we could say we'll have a stable=20 > draft with a matching implementation. By then, I suspect the=20 > security design for LISP will be ready as well. ack that is pretty aggressive thanks. >=20 > > I hope we can move in this direction and it left doors open for=20 > > ongoing and future work esp. for end-to-end. >=20 > What do you mean? Is this a general comment or one=20 > specifically related to LISP? General comment. Bottom line my test for end-to-end is if you and I want to talk over IM on the net and we want defense in depth we both can encrypt as peers all but our IP headers and only way we can be attacked at the IP layer is if a criminal has the money to crack the level of encryption we use. Intermeidate nodes between us simply get the packets to us in the best way they can with the IP header and protect that packet via DPI, IDP, etc. witihout peeking at TCP or UDP. Thats all. >=20 > > A suggestion is make the draft IP version agnostic and yes=20 > this will=20 > > work with IPv6 on first two general reads. I am willing to=20 > help you=20 > > do this if you want the help. >=20 > Sure, I will do this in the second draft. In fact, I am=20 > contemplating having "mixed mode mappings" where one could=20 > have a v4-EID to v6-RLOC mapping or maybe more useful a=20 > v6-EID to v4-RLOC mapping. Thanks. >=20 > > I also believe it is transparent to Mobile IP work and for me that=20 > > problem is solved and LISP does not preclude using what we=20 > have today,=20 > > but will make it more efficient (hand waving here for now yes). >=20 > Right. Do you have an opinion if it could be used instead of=20 > the mobile-IP work? Just wondering, not really advocating it. Right now can't type all I want to because of the day job :--). But I do believe LISP can extend via the RLOC the scope or diameter of the networks I roam before I need a new care of address. I still think we need the care of address and all that goes with it for global seamless IP mobility ergo yes we still need Mobile IP but LISP can make it more efficient. Glad to on about this in another mail if useful. >=20 > > This architecture assumes PI space for all sites is globally in the=20 > > DNS. > > Do you agree with that assumption? >=20 > PI or PA. It doesn't assume much from the structure of the=20 > address hosts insert in IP headers. But depending on where=20 > you put the ITRs and ETRs, there is "internal routing" based=20 > on these addresses. Ack. >=20 > > A question will there be any IPR claims on the LISP architecture? >=20 > No there will not be. I stated to the IAB that we (or at=20 > least I) will attempt to work with the IETF process and keep=20 > this work open. Thank You Very Much it is important we all work like this IMHO it breeds open systems view from the IETF with honor. >=20 > >> LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC > >> mappings; such routing is via a separate topology. > > > > Then from EID definition: > > > >> LISP uses PI blocks for EIDs; such EIDs MUST > >> NOT be used as a LISP RLOCs. >=20 > Right, when we say "routable" we don't necessarily mean on=20 > the capital-I Internet. We want to have a data triggered=20 > event to avoid packet loss. Remember, the routers don't have=20 > the advantage of connection setup, unless we hack TCP-syn=20 > snooping in the ITR. Ack. >=20 > PI blocks are routable today. I realize we want to reduce the=20 > amount of PI prefixes in the core and if possible eliminate=20 > them altogether. =20 > So that is why we indicated we could route these packets (for=20 > rare bootstraping cases) on another/smaller/cost-reduced/performance- > reduced infrastructure. >=20 > > Does the above mean EIDs cannot use PA's? >=20 > They can. Ack. >=20 > > I believe there are cases within LISP where optimizations are=20 > > necessary to reduce the LISP processing at the edge and tunnel=20 > > processing where the source packet is capable of simply passing=20 > > through the LISP site topology. I am sure you know the mission=20 > > critical use cases here so I will not note them for now. >=20 > Sure, I think you can tag FIB entries. The ones that are=20 > tagged are the ones that would get LISP headers appended. Got it. Thanks for that education. >=20 > > Specifically: > > > >> o End-systems (hosts) only know about EIDs. > > > > I am fine with this but then there may be cases where end-system=20 > > becomes intermediate node or something to that effect to=20 > address the=20 > > use cases for optimizations I reference above. >=20 > I saw your reference but please elaborate more on it. You answered by the tagging above. If packet is not tagged can I assume it is not tunneled to the ETR? >=20 > > This could produce a new set of new type of edge=20 > boxes/software in the=20 > > market too should we consider those consequences, as=20 > discussed under=20 > > ITR terminology. >=20 > You mean like a NAT? ;-) No I don't see LISP causing NAT but could help IPv6 NAP for sure for transition. Bandwidth Brokers, Deep Packet Inspection Optimizations via Hardware, new Session Control nodes to support IMS, Streaming, or even NSIS.=20 >=20 > >> Some of the design goals of this proposal include: > > > > I think we need to add multi-homing to this set of goals too. >=20 > Well, it certainly is an indirect goal where if you satisfy=20 > the stated goals, you get multi-homing as well. But in the=20 > next rev, we will make that more clear. Ack. >=20 > > And from PA defintion below: > > > >> Traditionally, IP multihoming has been implemented by each multi-=20 > >> homed > > site acquiring > >> its own, globally-visible prefix. LISP uses only > > topologically-assigned and > >> aggregatable address blocks for RLOCs, eliminating this=20 > demonstrably > > non-scalable > >> practice. > > > > I think the above will assist with the multi-homing problem and=20 > > suggest we need section in the draft why that is true. >=20 > Okay, will add. Great maybe if you and authors are comfortable adding that to the results from LISP would be a valid entry then. >=20 > >> Egress Tunnel Router (ETR): a router that accepts an IP packet > >> where destination address in the "outer" IP header is=20 > one of its > >> own RLOCs. The router strips the "outer" header and=20 > forwards the > >> packet based on the next IP header found. In general, an ETR > >> receives LISP-encapsulated IP packets from the Internet on one > >> side and sends decapsulated IP packets to site=20 > end-systems on the=20 > >> other side. > > > > Assuming here below the ETR is the last router within a site to=20 > > forward a packet to the destination over an Intranet or Internet? >=20 > I can't parse your sentence to know what you really mean. But=20 > I can say the ETR is the router that removes the outer LISP=20 > header and will then route the packet based on the inner=20 > header. If the ETR is directly connected to the destination=20 > host, then the destination address is used to do a ARP lookup=20 > (after it determines the destination resides on an attached=20 > subnet). In other cases, the ETR routes the packet that the=20 > IGP can deliver to the destination host. =20 > Therefore, the inner address is still routable "inside of the domain". I was on bad tangent. I was viewing ITR and ETR in same source node (EID) network. Thanks and sorry. >=20 > > Does not the above assume or state the ETR is sending the=20 > End Systems=20 > > IP packet which implies the End System IP header prior to=20 > ITR knew the > > RLOC? Seems confusing? >=20 > RLOCs are used for global routing, that is outside of a=20 > domain. We formalize it to mean the addresses in "the outer=20 > header". The original packet is routed like it is today. So I=20 > guess you can say it is a locator within a ETR's scope. Got it as I said bad tangent on my part, bad coffee :--). >=20 > > Section 4.1 Packet Flow Sequence #3 did not help me? > > > > LISP does not alter the orginal end-systems IP header is my read of=20 > > the spec? >=20 > Correct. But in LISP 1, we use the inner addresses to probe=20 > for an EID-to-RLOC mapping. Ack. I did see that one. >=20 > > o EIDs are not expected to be usable for end-to-end=20 > communication in > >> the absence of an EID-to-RLOC mapping operation. > > > > But, the end-system should be able to encrypt all but the IP header=20 > > (with IPv6 the options are in the clear too) and pass=20 > through the ITR=20 > > and ETR. In addtion this gets to the required=20 > optimizations above in=20 > > certain cases. >=20 > Yes, definitely. Ack. >=20 > > > >> o EIDs may also be structured (subnetted) in a manner suitable for > >> local routing within an autonomous system. > > > > Suggest change to "EID can also be ...." remove the connotation of=20 > > "MAY" > > above. >=20 > What do you suggest then? Changing it from "may" to "are"? "are" would work. >=20 > > I need to spend more time with sections 6,7,8,9,10. Probably will=20 > > send mail if required for each of them individually. >=20 > Cool. Thanks for your comments Jim. Thanks for your response too. /jim >=20 > Dino >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Feb 10 19:13:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG2Kg-0000gD-00; Sat, 10 Feb 2007 19:12:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0LV-0002RL-Bz for ram@iab.org; Sat, 10 Feb 2007 17:05:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0LT-0000Ae-29 for ram@iab.org; Sat, 10 Feb 2007 17:05:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2007 14:05:22 -0800 X-IronPort-AV: i="4.13,310,1167638400"; d="scan'208"; a="111241750:sNHT41241357" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1AM5MQR013441; Sat, 10 Feb 2007 14:05:22 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1AM5CDk001321; Sat, 10 Feb 2007 14:05:12 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:05:12 -0800 Received: from [192.168.0.4] ([10.21.99.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:05:11 -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: Dino Farinacci Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sat, 10 Feb 2007 14:05:11 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Feb 2007 22:05:11.0743 (UTC) FILETIME=[88E724F0:01C74D5F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=373; t=1171145122; x=1172009122; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20thoughts=20on=20draft-farinacci-lisp- 00 |Sender:=20; bh=asNaFEhUwR+DW2PykquUlgIxxxjqGsUK8kE0baEkZXY=; b=FjlB0ujrAG5ATmqGClp/xGYgHuIEFX42py02a1rPGytt9wG/2kxqqY6YuBU4hwlBYGvz88LE n01WN3cgL4cZzg0yXbHhFJbzy9iHGYiyvldYlOUNMArWkjaVnc7auLeb; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Sat, 10 Feb 2007 19:12:40 -0500 Cc: ram@iab.org, Jim.Bound@hp.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > And let me add another favoring aspect: > The ETR would also be a perfect fit for being a CTR (cascade tree > router) by which DDoS attacks could be outsmarted and become > ineffective as I pointed out by some prevous email (to arch-d I > think). Thanks for the kind words. Could you explain what you mean by outsmarting DDos attacks in the ETR? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Feb 10 19:13:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG2Kg-0000gJ-6u; Sat, 10 Feb 2007 19:12:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.iFrom ram-bounces@iab.org Sat Feb 10 19:13:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG2Kg-0000gD-00; Sat, 10 Feb 2007 19:12:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0LV-0002RL-Bz for ram@iab.org; Sat, 10 Feb 2007 17:05:25 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0LT-0000Ae-29 for ram@iab.org; Sat, 10 Feb 2007 17:05:25 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2007 14:05:22 -0800 X-IronPort-AV: i="4.13,310,1167638400"; d="scan'208"; a="111241750:sNHT41241357" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1AM5MQR013441; Sat, 10 Feb 2007 14:05:22 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1AM5CDk001321; Sat, 10 Feb 2007 14:05:12 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:05:12 -0800 Received: from [192.168.0.4] ([10.21.99.200]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:05:11 -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: Dino Farinacci Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sat, 10 Feb 2007 14:05:11 -0800 To: HeinerHummel@aol.com X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Feb 2007 22:05:11.0743 (UTC) FILETIME=[88E724F0:01C74D5F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=373; t=1171145122; x=1172009122; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20thoughts=20on=20draft-farinacci-lisp- 00 |Sender:=20; bh=asNaFEhUwR+DW2PykquUlgIxxxjqGsUK8kE0baEkZXY=; b=FjlB0ujrAG5ATmqGClp/xGYgHuIEFX42py02a1rPGytt9wG/2kxqqY6YuBU4hwlBYGvz88LE n01WN3cgL4cZzg0yXbHhFJbzy9iHGYiyvldYlOUNMArWkjaVnc7auLeb; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de X-Mailman-Approved-At: Sat, 10 Feb 2007 19:12:40 -0500 Cc: ram@iab.org, Jim.Bound@hp.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > And let me add another favoring aspect: > The ETR would also be a perfect fit for being a CTR (cascade tree > router) by which DDoS attacks could be outsmarted and become > ineffective as I pointed out by some prevous email (to arch-d I > think). Thanks for the kind words. Could you explain what you mean by outsmarting DDos attacks in the ETR? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Feb 10 19:13:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG2Kg-0000gJ-6u; Sat, 10 Feb 2007 19:12:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0hL-0007lv-Sv for ram@iab.org; Sat, 10 Feb 2007 17:27:59 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0hK-0004tX-6v for ram@iab.org; Sat, 10 Feb 2007 17:27:59 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2007 14:27:57 -0800 X-IronPort-AV: i="4.13,310,1167638400"; d="scan'208"; a="111247246:sNHT59829831" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1AMRvXN029270; Sat, 10 Feb 2007 14:27:57 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1AMRvGk021991; Sat, 10 Feb 2007 14:27:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:27:55 -0800 Received: from [192.168.0.4] ([10.21.99.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:27:55 -0800 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> References: <45BE2530.2050600@piuha.net> <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B8DEB5C-B4BE-48FA-9A23-66B998640A8F@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sat, 10 Feb 2007 14:27:55 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Feb 2007 22:27:55.0378 (UTC) FILETIME=[B5B15520:01C74D62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7327; t=1171146477; x=1172010477; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20thoughts=20on=20draft-farinacci-lisp- 00 |Sender:=20; bh=obS2EoEO7OdtM71csh0DvclO+Tbmv2+oAJqk8aGc0rk=; b=W4lFO2mq33muXNhZZjhIpu8cETBYOwEeLjzfpmXMg1G00tDZ50G3z1EdVs1yik53vkSL+yvo YrPi5mousnWDGxsnROxGeLR/SYA9Q/kzevg/+o2pCYPS+VIkcz6jnTVK; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-Mailman-Approved-At: Sat, 10 Feb 2007 19:12:40 -0500 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I like very much this technology approach using LISP to resolve RAM > issues. Great job by you, Dave, and Vince and contribution to the > IETF. Thanks Jim. > Suggest you target stable draft for July Chicago meeting Prague is far > to soon. Then shift right other time frames. Well my personal plan was to have a prototype available for people to play with. So we could say we'll have a stable draft with a matching implementation. By then, I suspect the security design for LISP will be ready as well. > I hope we can move in this direction and it left doors open for > ongoing > and future work esp. for end-to-end. What do you mean? Is this a general comment or one specifically related to LISP? > A suggestion is make the draft IP version agnostic and yes this will > work with IPv6 on first two general reads. Ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG0hL-0007lv-Sv for ram@iab.org; Sat, 10 Feb 2007 17:27:59 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG0hK-0004tX-6v for ram@iab.org; Sat, 10 Feb 2007 17:27:59 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 10 Feb 2007 14:27:57 -0800 X-IronPort-AV: i="4.13,310,1167638400"; d="scan'208"; a="111247246:sNHT59829831" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1AMRvXN029270; Sat, 10 Feb 2007 14:27:57 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1AMRvGk021991; Sat, 10 Feb 2007 14:27:57 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:27:55 -0800 Received: from [192.168.0.4] ([10.21.99.200]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 14:27:55 -0800 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> References: <45BE2530.2050600@piuha.net> <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B8DEB5C-B4BE-48FA-9A23-66B998640A8F@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sat, 10 Feb 2007 14:27:55 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Feb 2007 22:27:55.0378 (UTC) FILETIME=[B5B15520:01C74D62] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7327; t=1171146477; x=1172010477; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20thoughts=20on=20draft-farinacci-lisp- 00 |Sender:=20; bh=obS2EoEO7OdtM71csh0DvclO+Tbmv2+oAJqk8aGc0rk=; b=W4lFO2mq33muXNhZZjhIpu8cETBYOwEeLjzfpmXMg1G00tDZ50G3z1EdVs1yik53vkSL+yvo YrPi5mousnWDGxsnROxGeLR/SYA9Q/kzevg/+o2pCYPS+VIkcz6jnTVK; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c X-Mailman-Approved-At: Sat, 10 Feb 2007 19:12:40 -0500 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I like very much this technology approach using LISP to resolve RAM > issues. Great job by you, Dave, and Vince and contribution to the > IETF. Thanks Jim. > Suggest you target stable draft for July Chicago meeting Prague is far > to soon. Then shift right other time frames. Well my personal plan was to have a prototype available for people to play with. So we could say we'll have a stable draft with a matching implementation. By then, I suspect the security design for LISP will be ready as well. > I hope we can move in this direction and it left doors open for > ongoing > and future work esp. for end-to-end. What do you mean? Is this a general comment or one specifically related to LISP? > A suggestion is make the draft IP version agnostic and yes this will > work with IPv6 on first two general reads. I am willing to help > you do > this if you want the help. Sure, I will do this in the second draft. In fact, I am contemplating having "mixed mode mappings" where one could have a v4-EID to v6-RLOC mapping or maybe more useful a v6-EID to v4-RLOC mapping. > I also believe it is transparent to Mobile IP work and for me that > problem is solved and LISP does not preclude using what we have today, > but will make it more efficient (hand waving here for now yes). Right. Do you have an opinion if it could be used instead of the mobile-IP work? Just wondering, not really advocating it. > This architecture assumes PI space for all sites is globally in the > DNS. > Do you agree with that assumption? PI or PA. It doesn't assume much from the structure of the address hosts insert in IP headers. But depending on where you put the ITRs and ETRs, there is "internal routing" based on these addresses. > A question will there be any IPR claims on the LISP architecture? No there will not be. I stated to the IAB that we (or at least I) will attempt to work with the IETF process and keep this work open. >> LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC >> mappings; such routing is via a separate topology. > > Then from EID definition: > >> LISP uses PI blocks for EIDs; such EIDs MUST >> NOT be used as a LISP RLOCs. Right, when we say "routable" we don't necessarily mean on the capital-I Internet. We want to have a data triggered event to avoid packet loss. Remember, the routers don't have the advantage of connection setup, unless we hack TCP-syn snooping in the ITR. PI blocks are routable today. I realize we want to reduce the amount of PI prefixes in the core and if possible eliminate them altogether. So that is why we indicated we could route these packets (for rare bootstraping cases) on another/smaller/cost-reduced/performance- reduced infrastructure. > Does the above mean EIDs cannot use PA's? They can. > I believe there are cases within LISP where optimizations are > necessary > to reduce the LISP processing at the edge and tunnel processing where > the source packet is capable of simply passing through the LISP site > topology. I am sure you know the mission critical use cases here so I > will not note them for now. Sure, I think you can tag FIB entries. The ones that are tagged are the ones that would get LISP headers appended. > Specifically: > >> o End-systems (hosts) only know about EIDs. > > I am fine with this but then there may be cases where end-system > becomes > intermediate node or something to that effect to address the use cases > for optimizations I reference above. I saw your reference but please elaborate more on it. > This could produce a new set of new type of edge boxes/software in the > market too should we consider those consequences, as discussed > under ITR > terminology. You mean like a NAT? ;-) >> Some of the design goals of this proposal include: > > I think we need to add multi-homing to this set of goals too. Well, it certainly is an indirect goal where if you satisfy the stated goals, you get multi-homing as well. But in the next rev, we will make that more clear. > And from PA defintion below: > >> Traditionally, IP multihoming has been implemented by each multi- >> homed > site acquiring >> its own, globally-visible prefix. LISP uses only > topologically-assigned and >> aggregatable address blocks for RLOCs, eliminating this demonstrably > non-scalable >> practice. > > I think the above will assist with the multi-homing problem and > suggest > we need section in the draft why that is true. Okay, will add. >> Egress Tunnel Router (ETR): a router that accepts an IP packet >> where destination address in the "outer" IP header is one of its >> own RLOCs. The router strips the "outer" header and forwards the >> packet based on the next IP header found. In general, an ETR >> receives LISP-encapsulated IP packets from the Internet on one >> side and sends decapsulated IP packets to site end- am willing to help > you do > this if you want the help. Sure, I will do this in the second draft. In fact, I am contemplating having "mixed mode mappings" where one could have a v4-EID to v6-RLOC mapping or maybe more useful a v6-EID to v4-RLOC mapping. > I also believe it is transparent to Mobile IP work and for me that > problem is solved and LISP does not preclude using what we have today, > but will make it more efficient (hand waving here for now yes). Right. Do you have an opinion if it could be used instead of the mobile-IP work? Just wondering, not really advocating it. > This architecture assumes PI space for all sites is globally in the > DNS. > Do you agree with that assumption? PI or PA. It doesn't assume much from the structure of the address hosts insert in IP headers. But depending on where you put the ITRs and ETRs, there is "internal routing" based on these addresses. > A question will there be any IPR claims on the LISP architecture? No there will not be. I stated to the IAB that we (or at least I) will attempt to work with the IETF process and keep this work open. >> LISP 1.5: where EIDs are routable for bootstrapping EID-to-RLOC >> mappings; such routing is via a separate topology. > > Then from EID definition: > >> LISP uses PI blocks for EIDs; such EIDs MUST >> NOT be used as a LISP RLOCs. Right, when we say "routable" we don't necessarily mean on the capital-I Internet. We want to have a data triggered event to avoid packet loss. Remember, the routers don't have the advantage of connection setup, unless we hack TCP-syn snooping in the ITR. PI blocks are routable today. I realize we want to reduce the amount of PI prefixes in the core and if possible eliminate them altogether. So that is why we indicated we could route these packets (for rare bootstraping cases) on another/smaller/cost-reduced/performance- reduced infrastructure. > Does the above mean EIDs cannot use PA's? They can. > I believe there are cases within LISP where optimizations are > necessary > to reduce the LISP processing at the edge and tunnel processing where > the source packet is capable of simply passing through the LISP site > topology. I am sure you know the mission critical use cases here so I > will not note them for now. Sure, I think you can tag FIB entries. The ones that are tagged are the ones that would get LISP headers appended. > Specifically: > >> o End-systems (hosts) only know about EIDs. > > I am fine with this but then there may be cases where end-system > becomes > intermediate node or something to that effect to address the use cases > for optimizations I reference above. I saw your reference but please elaborate more on it. > This could produce a new set of new type of edge boxes/software in the > market too should we consider those consequences, as discussed > under ITR > terminology. You mean like a NAT? ;-) >> Some of the design goals of this proposal include: > > I think we need to add multi-homing to this set of goals too. Well, it certainly is an indirect goal where if you satisfy the stated goals, you get multi-homing as well. But in the next rev, we will make that more clear. > And from PA defintion below: > >> Traditionally, IP multihoming has been implemented by each multi- >> homed > site acquiring >> its own, globally-visible prefix. LISP uses only > topologically-assigned and >> aggregatable address blocks for RLOCs, eliminating this demonstrably > non-scalable >> practice. > > I think the above will assist with the multi-homing problem and > suggest > we need section in the draft why that is true. Okay, will add. >> Egress Tunnel Router (ETR): a router that accepts an IP packet >> where destination address in the "outer" IP header is one of its >> own RLOCs. The router strips the "outer" header and forwards the >> packet based on the next IP header found. In general, an ETR >> receives LISP-encapsulated IP packets from the Internet on one >> side and sends decapsulated IP packets to site end-systems on the >> other side. > > Assuming here below the ETR is the last router within a site to > forward > a packet to the destination over an Intranet or Internet? I can't parse your sentence to know what you really mean. But I can say the ETR is the router that removes the outer LISP header and will then route the packet based on the inner header. If the ETR is directly connected to the destination host, then the destination address is used to do a ARP lookup (after it determines the destination resides on an attached subnet). In other cases, the ETR routes the packet that the IGP can deliver to the destination host. Therefore, the inner address is still routable "inside of the domain". > Does not the above assume or state the ETR is sending the End > Systems IP > packet which implies the End System IP header prior to ITR knew the > RLOC? Seems confusing? RLOCs are used for global routing, that is outside of a domain. We formalize it to mean the addresses in "the outer header". The original packet is routed like it is today. So I guess you can say it is a locator within a ETR's scope. > Section 4.1 Packet Flow Sequence #3 did not help me? > > LISP does not alter the orginal end-systems IP header is my read of > the > spec? Correct. But in LISP 1, we use the inner addresses to probe for an EID-to-RLOC mapping. > o EIDs are not expected to be usable for end-to-end communication in >> the absence of an EID-to-RLOC mapping operation. > > But, the end-system should be able to encrypt all but the IP header > (with IPv6 the options are in the clear too) and pass through the ITR > and ETR. In addtion this gets to the required optimizations above in > certain cases. Yes, definitely. > >> o EIDs may also be structured (subnetted) in a manner suitable for >> local routing within an autonomous system. > > Suggest change to "EID can also be ...." remove the connotation of > "MAY" > above. What do you suggest then? Changing it from "may" to "are"? > I need to spend more time with sections 6,7,8,9,10. Probably will > send > mail if required for each of them individually. Cool. Thanks for your comments Jim. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram systems on the >> other side. > > Assuming here below the ETR is the last router within a site to > forward > a packet to the destination over an Intranet or Internet? I can't parse your sentence to know what you really mean. But I can say the ETR is the router that removes the outer LISP header and will then route the packet based on the inner header. If the ETR is directly connected to the destination host, then the destination address is used to do a ARP lookup (after it determines the destination resides on an attached subnet). In other cases, the ETR routes the packet that the IGP can deliver to the destination host. Therefore, the inner address is still routable "inside of the domain". > Does not the above assume or state the ETR is sending the End > Systems IP > packet which implies the End System IP header prior to ITR knew the > RLOC? Seems confusing? RLOCs are used for global routing, that is outside of a domain. We formalize it to mean the addresses in "the outer header". The original packet is routed like it is today. So I guess you can say it is a locator within a ETR's scope. > Section 4.1 Packet Flow Sequence #3 did not help me? > > LISP does not alter the orginal end-systems IP header is my read of > the > spec? Correct. But in LISP 1, we use the inner addresses to probe for an EID-to-RLOC mapping. > o EIDs are not expected to be usable for end-to-end communication in >> the absence of an EID-to-RLOC mapping operation. > > But, the end-system should be able to encrypt all but the IP header > (with IPv6 the options are in the clear too) and pass through the ITR > and ETR. In addtion this gets to the required optimizations above in > certain cases. Yes, definitely. > >> o EIDs may also be structured (subnetted) in a manner suitable for >> local routing within an autonomous system. > > Suggest change to "EID can also be ...." remove the connotation of > "MAY" > above. What do you suggest then? Changing it from "may" to "are"? > I need to spend more time with sections 6,7,8,9,10. Probably will > send > mail if required for each of them individually. Cool. Thanks for your comments Jim. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Feb 11 02:31:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG99B-0007c0-DZ; Sun, 11 Feb 2007 02:29:17 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HG99A-0007bv-9P for ram@iab.org; Sun, 11 Feb 2007 02:29:16 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HG998-0003vd-UN for ram@iab.org; Sun, 11 Feb 2007 02:29:16 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 10 Feb 2007 23:29:10 -0800 X-IronPort-AV: i="4.13,310,1167638400"; d="scan'208"; a="387884472:sNHT50345726" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1B7TAjk003426; Sat, 10 Feb 2007 23:29:10 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1B7T9Dk016138; Sat, 10 Feb 2007 23:29:09 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 23:29:09 -0800 Received: from [192.168.0.4] ([10.21.98.236]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 10 Feb 2007 23:29:09 -0800 In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0154FC01@tayexc14.americas.cpqcorp.net> References: <45BE2530.2050600@piuha.net> <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> <3B8DEB5C-B4BE-48FA-9A23-66B998640A8F@cisco.com> <816DD9299957E547B5D758D7F977D6DC0154FC01@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <13BAAAD3-272A-44AD-92B8-4C4AD06CC4AB@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sat, 10 Feb 2007 23:29:09 -0800 To: "Bound, Jim" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Feb 2007 07:29:09.0078 (UTC) FILETIME=[5186B760:01C74DAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2940; t=1171178950; x=1172042950; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Re=3A=20thoughts=20on=20draft-farinacci-lisp- 00 |Sender:=20; bh=BOnAhYcmy4ZUZqsKyh0CIfMzT8vybkPeE7TiChYgVVw=; b=D6q3IO72tyeT/U646C+M0fKg8eVFffTrRlx7zivSBXJxHjsE9UZfVTFUI5q95NXoRxCwf/qC DVcHk+JGmCyijPzIBArzNmCqSVq68+pz+vpgUwuRs8EOpxTRVNbUgd4/; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> Suggest you target stable draft for July Chicago meeting >> Prague is far >>> to soon. Then shift right other time frames. >> >> Well my personal plan was to have a prototype available for >> people to play with. So we could say we'll have a stable >> draft with a matching implementation. By then, I suspect the >> security design for LISP will be ready as well. > > ack that is pretty aggressive thanks. Well the idea is fairly simple and we'll prototype a software only implementation so I think it is doable. >>> I hope we can move in this direction and it left doors open for >>> ongoing and future work esp. for end-to-end. >> >> What do you mean? Is this a general comment or one >> specifically related to LISP? > > General comment. Bottom line my test for end-to-end is if you and I > want to talk over IM on the net and we want defense in depth we > both can > encrypt as peers all but our IP headers and only way we can be > attacked > at the IP layer is if a criminal has the money to crack the level of > encryption we use. Intermeidate nodes between us simply get the > packets > to us in the best way they can with the IP header and protect that > packet via DPI, IDP, etc. witihout peeking at TCP or UDP. Thats all. Okay. >>> becomes intermediate node or something to that effect to >> address the >>> use cases for optimizations I reference above. >> >> I saw your reference but please elaborate more on it. > > You answered by the tagging above. If packet is not tagged can I > assume > it is not tunneled to the ETR? Right. >> You mean like a NAT? ;-) > > No I don't see LISP causing NAT but could help IPv6 NAP for sure for > transition. Bandwidth Brokers, Deep Packet Inspection Optimizations > via > Hardware, new Session Control nodes to support IMS, Streaming, or even > NSIS. Okay, I will need a verbal explanation of this. Maybe at IETF. >>> I think the above will assist with the multi-homing problem and >>> suggest we need section in the draft why that is true. >> >> Okay, will add. > > Great maybe if you and authors are comfortable adding that to the > results from LISP would be a valid entry then. Ack. >> I can't parse your sentence to know what you really mean. But >> I can say the ETR is the router that removes the outer LISP >> header and will then route the packet based on the inner >> header. If the ETR is directly connected to the destination >> host, then the destination address is used to do a ARP lookup >> (after it determines the destination resides on an attached >> subnet). In other cases, the ETR routes the packet that the >> IGP can deliver to the destination host. >> Therefore, the inner address is still routable "inside of the >> domain". > > I was on bad tangent. I was viewing ITR and ETR in same source node > (EID) network. > Thanks and sorry. Okay. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Feb 11 09:20:35 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGFWv-0002mg-FB; Sun, 11 Feb 2007 09:18:13 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGFWt-0002mG-Th for ram@ietf.org; Sun, 11 Feb 2007 09:18:11 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGFWt-0004Lw-LJ for ram@ietf.org; Sun, 11 Feb 2007 09:18:11 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1BEI602054196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Sun, 11 Feb 2007 15:18:06 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@ietf.org From: Iljitsch van Beijnum Date: Sun, 11 Feb 2007 15:17:55 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: Subject: [RAM] draft-farinacci-lisp-00.txt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I've read this draft but I found both the draft and the protocol/ proposal convoluted and hard to understand. (Please don't use a definitions section, but rather, use common terms even if they're a bit longer. I know definitions are necessary in protocol documents, but we're in the discussion phase here.) My main question: It looks like the first packet is routed based on the identifier. Wouldn't this require the existing routing infrastructure to remain in existence in some form? _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Feb 11 12:46:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGIlY-0003Xx-QY; Sun, 11 Feb 2007 12:45:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGIlX-0003Xj-MW for ram@iab.org; Sun, 11 Feb 2007 12:45:31 -0500 Received: from tayrelbas03.tay.hp.com ([161.114.80.246]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGIlR-0004QV-87 for ram@iab.org; Sun, 11 Feb 2007 12:45:31 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas03.tay.hp.com (Postfix) with ESMTP id 8C5EF3401E; Sun, 11 Feb 2007 12:45:22 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sun, 11 Feb 2007 12:45:22 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Re: thoughts on draft-farinacci-lisp-00 Date: Sun, 11 Feb 2007 12:45:20 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0154FC5F@tayexc14.americas.cpqcorp.net> In-Reply-To: <13BAAAD3-272A-44AD-92B8-4C4AD06CC4AB@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: thoughts on draft-farinacci-lisp-00 Thread-index: AcdNrlQ2FP0gbBoiSSWAAGKfNpjO4wAVajfw References: <45BE2530.2050600@piuha.net> <79B943E2-B125-4337-9993-8C5263F80D90@cisco.com> <816DD9299957E547B5D758D7F977D6DC0150B171@tayexc14.americas.cpqcorp.net> <3B8DEB5C-B4BE-48FA-9A23-66B998640A8F@cisco.com> <816DD9299957E547B5D758D7F977D6DC0154FC01@tayexc14.americas.cpqcorp.net> <13BAAAD3-272A-44AD-92B8-4C4AD06CC4AB@cisco.com> From: "Bound, Jim" To: "Dino Farinacci" X-OriginalArrivalTime: 11 Feb 2007 17:45:22.0173 (UTC) FILETIME=[67354AD0:01C74E04] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino, ack. Will be at Prague I just made the mental commitment this weekend (almost the 3rd IETF meeting I would have missed since 1991 just tired of travel as of late) to travel yet again on planes and will register so if we can find some time to talk that would be cool. IETF work is important clearly. thx /jim=20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Sunday, February 11, 2007 2:29 AM > To: Bound, Jim > Cc: Jari Arkko; ram@iab.org > Subject: Re: [RAM] Re: thoughts on draft-farinacci-lisp-00 >=20 > >>> Suggest you target stable draft for July Chicago meeting > >> Prague is far > >>> to soon. Then shift right other time frames. > >> > >> Well my personal plan was to have a prototype available=20 > for people to=20 > >> play with. So we could say we'll have a stable draft with=20 > a matching=20 > >> implementation. By then, I suspect the security design for=20 > LISP will=20 > >> be ready as well. > > > > ack that is pretty aggressive thanks. >=20 > Well the idea is fairly simple and we'll prototype a software=20 > only implementation so I think it is doable. >=20 > >>> I hope we can move in this direction and it left doors open for=20 > >>> ongoing and future work esp. for end-to-end. > >> > >> What do you mean? Is this a general comment or one specifically=20 > >> related to LISP? > > > > General comment. Bottom line my test for end-to-end is if=20 > you and I=20 > > want to talk over IM on the net and we want defense in=20 > depth we both=20 > > can encrypt as peers all but our IP headers and only way we can be=20 > > attacked at the IP layer is if a criminal has the money to=20 > crack the=20 > > level of encryption we use. Intermeidate nodes between us=20 > simply get=20 > > the packets to us in the best way they can with the IP header and=20 > > protect that packet via DPI, IDP, etc. witihout peeking at=20 > TCP or UDP. =20 > > Thats all. >=20 > Okay. >=20 > >>> becomes intermediate node or something to that effect to > >> address the > >>> use cases for optimizations I reference above. > >> > >> I saw your reference but please elaborate more on it. > > > > You answered by the tagging above. If packet is not tagged can I=20 > > assume it is not tunneled to the ETR? >=20 > Right. >=20 > >> You mean like a NAT? ;-) > > > > No I don't see LISP causing NAT but could help IPv6 NAP for=20 > sure for=20 > > transition. Bandwidth Brokers, Deep Packet Inspection Optimizations=20 > > via Hardware, new Session Control nodes to support IMS,=20 > Streaming, or=20 > > even NSIS. >=20 > Okay, I will need a verbal explanation of this. Maybe at IETF. >=20 > >>> I think the above will assist with the multi-homing problem and=20 > >>> suggest we need section in the draft why that is true. > >> > >> Okay, will add. > > > > Great maybe if you and authors are comfortable adding that to the=20 > > results from LISP would be a valid entry then. >=20 > Ack. >=20 > >> I can't parse your sentence to know what you really mean.=20 > But I can=20 > >> say the ETR is the router that removes the outer LISP=20 > header and will=20 > >> then route the packet based on the inner header. If the ETR is=20 > >> directly connected to the destination host, then the destination=20 > >> address is used to do a ARP lookup (after it determines the=20 > >> destination resides on an attached subnet). In other=20 > cases, the ETR=20 > >> routes the packet that the IGP can deliver to the destination host. > >> Therefore, the inner address is still routable "inside of the=20 > >> domain". > > > > I was on bad tangent. I was viewing ITR and ETR in same source node > > (EID) network. > > Thanks and sorry. >=20 > Okay. >=20 > Dino >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 02:52:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGsPR-0002Mo-6X; Tue, 13 Feb 2007 02:49:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGsPP-0002Mg-RD for ram@ietf.org; Tue, 13 Feb 2007 02:49:03 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGsPL-0002r1-9u for ram@ietf.org; Tue, 13 Feb 2007 02:49:03 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 80EFD198777; Tue, 13 Feb 2007 09:48:44 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 21C14198774; Tue, 13 Feb 2007 09:48:44 +0200 (EET) Message-ID: <45D16D5C.5080104@piuha.net> Date: Tue, 13 Feb 2007 09:48:44 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: [RAM] Some Relevant Presentations at the recent NANOG References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Thanks for posting these, they were indeed useful. I found John Scudder's presentation particularly interesting. The interesting part wasn't really the current number of routes, but rather what he said about how this tracks hardware component development. I think he said 10M route entries could be reached with current design, merely by adding more DRAM. My understanding is that similar designs based more on commodity hardware components such as DRAMs exist also from other vendors. Of course, this does not mean that there are no issues; bottlenecks may still exist elsewhere in the system, and upgrading to new product architectures will be costly for the providers. The other part that I found interesting was that multiple vendors talked about compression mechanisms that make the FIB fit a smaller memory. Some of the providers were worried about such techniques. It was unclear to me if the techniques were so aggressive that they might change the behaviour, or if it was merely an issue of an algorithmic conversion to an equal but smaller size table. The latter seems workable, the former could lead to loops etc. One presentation that you did not mention below was http://www.nanog.org/mtg-0702/presentations/smith-lightning.pdf This discusses the growth of de-aggregation, and argues that there is more de-aggregation in the "newer" parts of the network, such as in Asia and Africa, with some ASNs having many prefixes (up to 1000) that could perhaps be saved with better BGP practices... Jari Marshall Eubanks kirjoitti: > Here is a list of presentations from this week's meeting that I think > might be relevant to this effort. In each case, it is title, followed > by html abstract followed by presentation(s). > > Pushing the FIB limits, perspectives on pressures confronting modern > routers. > http://www.nanog.org/mtg-0702/jaeggli.html > http://www.nanog.org/mtg-0702/presentations/fib-editorial.pdf > http://www.nanog.org/mtg-0702/presentations/fib-hankins.pdf > http://www.nanog.org/mtg-0702/presentations/fib-desilva.pdf > http://www.nanog.org/mtg-0702/presentations/fib-ryan.pdf > http://www.nanog.org/mtg-0702/presentations/fib-scudder.pdf (2 > million routes!) > http://www.nanog.org/mtg-0702/presentations/fib-atkinson.pdf > > Abstract: R-BGP: Ensuring Connectivity During BGP Convergence > http://www.nanog.org/mtg-0702/kushman.html > http://www.nanog.org/mtg-0702/presentations/Kushman.pdf > > Abstract: Introduction to Fast Convergence with Bidirectional > Forwarding Detection (BFD) > http://www.nanog.org/mtg-0702/akhter.html > http://www.nanog.org/mtg-0702/presentations/akhter.pdf > > Regards > Marshall Eubanks > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 03:14:54 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGsnq-0007JU-B5; Tue, 13 Feb 2007 03:14:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGsnp-0007JL-24 for ram@ietf.org; Tue, 13 Feb 2007 03:14:17 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGsnn-0006vM-PD for ram@ietf.org; Tue, 13 Feb 2007 03:14:17 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 13 Feb 2007 00:14:14 -0800 X-IronPort-AV: i="4.14,162,1170662400"; d="scan'208"; a="388462727:sNHT45177652" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1D8EDVU016379; Tue, 13 Feb 2007 00:14:13 -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 l1D8E8V0016889; Tue, 13 Feb 2007 00:14:13 -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); Tue, 13 Feb 2007 00:14:07 -0800 Received: from [192.168.0.101] ([10.21.81.162]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 00:14:07 -0800 In-Reply-To: <45D16D5C.5080104@piuha.net> References: <45D16D5C.5080104@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Some Relevant Presentations at the recent NANOG Date: Tue, 13 Feb 2007 00:14:05 -0800 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Feb 2007 08:14:07.0643 (UTC) FILETIME=[EED28EB0:01C74F46] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=859; t=1171354453; x=1172218453; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Some=20Relevant=20Presentations=20at=20the=20 recent=20NANOG |Sender:=20; bh=pPL3Q5Yu4tjVFcowmg3tZUwDmcmWFtEL0cu2L3xCjAw=; b=mwfOHSKr3ofeUBxUvJUwBk3D3A9KyPW4fAXVoL6tb2Nww6l5DTUbvg6XGs5DvW6bg+zVVv9x xLf+dkCvUjPvtXrWcshpUbXkeNqLnm9/cJ5XhtjQOp1nK/kfOox5BZv6; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > The other part that I found interesting was that > multiple vendors talked about compression mechanisms > that make the FIB fit a smaller memory. Some of > the providers were worried about such techniques. > It was unclear to me if the techniques were so > aggressive that they might change the behaviour, > or if it was merely an issue of an algorithmic > conversion to an equal but smaller size table. > The latter seems workable, the former could > lead to loops etc. Jari, Having worked on this in a previous life, there are plenty of techniques that (if properly implemented ;-), will provide semantically identical tables. This has been tested and shown to work. It has also been shown to be somewhat CPU intensive, so there are some side effects. It's just another time/space tradeoff at our disposal... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 03:27:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGt08-0004Fj-Gf; Tue, 13 Feb 2007 03:27:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGt06-0004Df-P5 for ram@ietf.org; Tue, 13 Feb 2007 03:26:58 -0500 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGt05-0000rD-GB for ram@ietf.org; Tue, 13 Feb 2007 03:26:58 -0500 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A2BCB198775; Tue, 13 Feb 2007 10:26:52 +0200 (EET) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 55A3F198774; Tue, 13 Feb 2007 10:26:52 +0200 (EET) Message-ID: <45D1764C.6020100@piuha.net> Date: Tue, 13 Feb 2007 10:26:52 +0200 From: Jari Arkko User-Agent: Thunderbird 1.5.0.9 (X11/20070104) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Some Relevant Presentations at the recent NANOG References: <45D16D5C.5080104@piuha.net> <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> In-Reply-To: <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Tony, > > Having worked on this in a previous life, there are plenty of > techniques that (if properly implemented ;-), will provide > semantically identical tables. This has been tested and shown to > work. It has also been shown to be somewhat CPU intensive, so there > are some side effects. It's just another time/space tradeoff at our > disposal... Right. I would expect the stuff to be reasonably easy to get right and test. Not a very hard thing in comparison many other things that we do with computers. Are the side effects what the providers are worried about? Or bugs, the inability to predict how well compression works for the given FIB memory size, or have people used non-semantically identical tables? Are there papers that analyze typical compression ratios in the current Internet? Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 04:24:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGtqz-0008OG-RI; Tue, 13 Feb 2007 04:21:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGtqy-0008O2-Rx for ram@ietf.org; Tue, 13 Feb 2007 04:21:36 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGtqx-0001Jr-Ia for ram@ietf.org; Tue, 13 Feb 2007 04:21:36 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 13 Feb 2007 01:21:35 -0800 X-IronPort-AV: i="4.14,162,1170662400"; d="scan'208"; a="464097892:sNHT43969780" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1D9LYvK032154; Tue, 13 Feb 2007 01:21:34 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1D9LSGk012272; Tue, 13 Feb 2007 01:21:28 -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, 13 Feb 2007 01:21:28 -0800 Received: from [192.168.0.101] ([10.21.81.162]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 01:21:27 -0800 In-Reply-To: <45D1764C.6020100@piuha.net> References: <45D16D5C.5080104@piuha.net> <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> <45D1764C.6020100@piuha.net> 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: [RAM] Some Relevant Presentations at the recent NANOG Date: Tue, 13 Feb 2007 01:21:25 -0800 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Feb 2007 09:21:27.0912 (UTC) FILETIME=[5702AE80:01C74F50] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=763; t=1171358495; x=1172222495; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=tli@cisco.com; z=From:=20Tony=20Li=20 |Subject:=20Re=3A=20[RAM]=20Some=20Relevant=20Presentations=20at=20the=20 recent=20NANOG |Sender:=20; bh=mqCIHC1syb8JQQGBENR5v3IvTEcGTsJbu0BRiY8OJHU=; b=pNfBnTfG3GXvyZTy/oI/fTccyUWHOLKV5XyTnDSGJQ1iZMT4YFBuG+UOrDMr91tPDg2FJ7Il cC6zF3kJJ7oZkb9LUiZ04/VQOJwWH+ORzusq8dccPypJ0AERJOk/0kU+; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Right. I would expect the stuff to be reasonably easy to > get right and test. Not a very hard thing in comparison > many other things that we do with computers. Are the > side effects what the providers are worried about? Or bugs, > the inability to predict how well compression works for the > given FIB memory size, or have people used non-semantically > identical tables? Without having spoken to them, I would assume that their first concern is bugs. Vendors have shown a remarkable ability to distribute flaws. Yours truly is one well-known perpetrator thereof. ;-) > Are there papers that analyze typical compression ratios > in the current Internet? I haven't seen any, but we were seeing 30% pretty easily. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 04:43:53 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGuC5-0003qY-Sb; Tue, 13 Feb 2007 04:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGuC4-0003qT-PN for ram@ietf.org; Tue, 13 Feb 2007 04:43:24 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGuC4-0003qL-Hn for ram@ietf.org; Tue, 13 Feb 2007 04:43:24 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fecd:987a] (alumange-giga.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fecd:987a]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1D9hHOi095842 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Feb 2007 10:43:18 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <45D1764C.6020100@piuha.net> References: <45D16D5C.5080104@piuha.net> <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> <45D1764C.6020100@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3F45391A-A4E7-4770-B5A2-21F795FB0878@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Some Relevant Presentations at the recent NANOG Date: Tue, 13 Feb 2007 10:43:08 +0100 To: Jari Arkko X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 13-feb-2007, at 9:26, Jari Arkko wrote: [FIB compression] > Are the > side effects what the providers are worried about? Or bugs, What I'm worried about is that this would introduce a measure of non- determinism. I.e., everything is working fine, FIB is compressed by 30% and 90% of the FIB space is in use. But then a few very unfortunate prefixes are added, compression goes down the toilet and we're at 105% of available FIB space... _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 04:57:41 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGuPQ-0002YA-LQ; Tue, 13 Feb 2007 04:57:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGuPP-0002Ss-1E for ram@ietf.org; Tue, 13 Feb 2007 04:57:11 -0500 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGuPM-0005VJ-OI for ram@ietf.org; Tue, 13 Feb 2007 04:57:11 -0500 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Feb 2007 04:57:08 -0500 X-IronPort-AV: i="4.14,162,1170651600"; d="scan'208"; a="113768038:sNHT44894520" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1D9v8Rn014195; Tue, 13 Feb 2007 04:57:08 -0500 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1D9v7OA002514; Tue, 13 Feb 2007 04:57:07 -0500 (EST) Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 04:57:07 -0500 Received: from [10.83.1.98] ([10.83.1.98]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 04:57:07 -0500 Message-ID: <45D18B75.1000808@cisco.com> Date: Tue, 13 Feb 2007 10:57:09 +0100 From: Mark Townsley User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] Some Relevant Presentations at the recent NANOG References: <45D16D5C.5080104@piuha.net> <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> <45D1764C.6020100@piuha.net> <3F45391A-A4E7-4770-B5A2-21F795FB0878@muada.com> In-Reply-To: <3F45391A-A4E7-4770-B5A2-21F795FB0878@muada.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Feb 2007 09:57:07.0250 (UTC) FILETIME=[5227C120:01C74F55] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=987; t=1171360628; x=1172224628; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=townsley@cisco.com; z=From:=20Mark=20Townsley=20 |Subject:=20Re=3A=20[RAM]=20Some=20Relevant=20Presentations=20at=20the=20 recent=20NANOG |Sender:=20 |To:=20Iljitsch=20van=20Beijnum=20; bh=zpPRvNO4qW/PFWIA56ndqat23ybj6W9MUBq9fdEomZw=; b=ziIR2/hFIGA37g0RS/Etpnxe4KuWGc4Wm4DxxwQO+1Oipc5HuVAOqlyuwCIdOwrY5q+WLb1M YjVuke3sT4WGMRxuKeebRVdmc1lNwgaDsJEr9Xha8c8ij0xOsCyru0xr; Authentication-Results: rtp-dkim-2; header.From=townsley@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org My very rough guess is that for designs based on a DRAM FIB, the benefit of compression vs. cost would be fairly low. On SRAM based systems, perhaps it is more advantageous. One thing that the set of NANOG presentations make very clear is that there are different architectures out there, each with different tradeoffs. - Mark Iljitsch van Beijnum wrote: > On 13-feb-2007, at 9:26, Jari Arkko wrote: > > [FIB compression] > >> Are the >> side effects what the providers are worried about? Or bugs, > > What I'm worried about is that this would introduce a measure of > non-determinism. I.e., everything is working fine, FIB is compressed > by 30% and 90% of the FIB space is in use. But then a few very > unfortunate prefixes are added, compression goes down the toilet and > we're at 105% of available FIB space... > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 13 06:30:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvqS-0006bO-7z; Tue, 13 Feb 2007 06:29:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HGvqQ-0006aR-MK for ram@ietf.org; Tue, 13 Feb 2007 06:29:10 -0500 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5133]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HGvqM-0001JD-60 for ram@ietf.org; Tue, 13 Feb 2007 06:29:10 -0500 Received: from 247.254.187.81.in-addr.arpa ([81.187.254.247]) by smtp.aaisp.net.uk with esmtps (TLSv1:AES256-SHA:256) (Exim 4.62) (envelope-from ) id 1HGvq0-00079x-2p; Tue, 13 Feb 2007 11:28:44 +0000 Message-ID: <45D1A119.9070008@dial.pipex.com> Date: Tue, 13 Feb 2007 11:29:29 +0000 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Jari Arkko Subject: Re: [RAM] Some Relevant Presentations at the recent NANOG References: <45D16D5C.5080104@piuha.net> <89487E3E-760F-4AD5-B9CE-07F1EA3BCFDF@cisco.com> <45D1764C.6020100@piuha.net> In-Reply-To: <45D1764C.6020100@piuha.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Tony Li , ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org [FIB Compression] > Are the side effects what the providers are worried about? Or bugs, > > Another major issue with clever FIB schemes whether compressed or otherwise is the cost/possibility of incremental updates. I haven't been involved with big router design for a while but a significant bottleneck was getting a large FIB out to each of a largish number of interface cards from the central controller and then updating it. If you end up with the need to replace the whole FIB (or even a significant chunk of it) to do an update this is bad news, and obviously gets worse as the FIB grows. As I understand it the gold standard for IP lookup algorithms at the moment is the Tree Bitmap algorithm (Eatherton, Varghese and Dittia) described in http://www.cs.cornell.edu/courses/cs419/2005sp/tree-bitmap.pdf. This uses a trie based structure with a kind of 'compression' into bitmaps that allows for incremental updates and is well matched to wide data path synchronous DRAM operations. According to Varghese's web page Cisco have confirmed that this algorithm is used in the CRS-1. This set of lecture notes is alleged to help explain how it works (but I am not so sure that it helps): http://www.cs.cornell.edu/courses/cs419/2005sp/419-sp05-06-fast-lookup-v0.pdf This paper http://www.arl.wustl.edu/~todd/fipl.pdf describes a research hardware implementation of the tree bitmap algorithm. This paper from 2001 covers most of the algorithms predating the tree bitmap algorithm (including its immediate ancestor the Lulea algorithm) and gives theoretical and practical comparisons of their performance both in lookups and updates: http://www.eurecom.fr/util/publidownload.en.htm?file=/homesdocs/publications/htdocs/ce/bierer-010301.pdf Regards, Elwyn _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 15 03:37:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHc4Z-0007ry-SX; Thu, 15 Feb 2007 03:34:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHc4Y-0007rY-IJ for ram@iab.org; Thu, 15 Feb 2007 03:34:34 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHc4W-0007UZ-2e for ram@iab.org; Thu, 15 Feb 2007 03:34:34 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 46894212D2E for ; Thu, 15 Feb 2007 10:34:28 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 0D354212D2C for ; Thu, 15 Feb 2007 10:34:28 +0200 (EET) Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: Pekka Nikander Date: Thu, 15 Feb 2007 10:34:21 +0200 X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Subject: [RAM] Architectural comments on draft-farinacci-lisp-00 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I finally had time to properly read draft-farinacci-lisp-00. To me, it is intriguing work from deployment and implementation point of view. However, it also seems to bear wider architectural similarities to what would be proxied SHIM6 or HIP, or any other proxied host-based identifier/locator split architecture. From an architectural point of view, I would divide the proposed mechanism into four different aspects: 1. Placement of the identifier / locator mapping function 2. Encapsulating of data packets 3. State creating between mapping points, i.e., the "protocol" 4. Trust models and security mechanisms Continuing from this architectural viewpoint, at least to me, the main feature of LISP is to place the identifier / locator mapping function into separate boxes in the network, not at the hosts. However, as I tied to outline in draft-nikander-ram-generix- proxying-00.txt, also host-based approaches allow such placement by "stretching" the stack into a wire. In the case of the EIDs being routable (as for LISP 1 or 1.5), there is also considerable freedom in placing the proxies in the network; see Section 7 of the draft. Considering the other aspects, LISP and any SHIM6/HIP based proxied approach are pretty similar. Both encapsulate the data packets somehow, at least conceptually*). Both need to create appropriate mapping state between the mapping points, and resynchronise the state in the case of mobility or state loss. Both need some mechanism for securing against traffic stealing, black-holing, and flooding. *) When ESP is used with HIP, actually no explicit encapsulation is needed since the ESP SPI can be used for demultiplexing the traffic at the decapsulating end. The differences are in details. The following table attempts to capture the crux. Approach | Encapsulation | Protocol | Security ---------+---------------+----------+------------------ LISP | IP tunnel | ICMP/new | not defined yet SHIM6 | Context tag | SHIM6 | HBA / CGA + RR HIP | IPsec ESP | HIP BE | ORCHID + RR Looking at the details, I don't see any fundamental differences in encapsulation. IP tunnelling could be easily used for SHIM6 and HIP, too. Basically, what SHIM6 and HIP provide are optimised tunnelling, i.e., headers that are optimised to carry the minimum amount of information needed so that the receiving end (ETR in LISP terminology) can re-create the original packet. If tunnelling (with all its known drawbacks) is considered to be a better encapsulation method that what is currently defined for SHIM6 or HIP, it would be a no-brainer to adjust SHIM6 and/or HIP accordingly. Looking at the protocols, SHIM6 and HIP base exchange carry known similarities; the SHIM6 protocol was inspired by HIP. The biggest advances of SHIM6 to HIP are its ability for late binding and lighter cryptographic operations. However, the LHIP proposal provides similar properties for HIP too, rendering the fundamental differences between SHIM6 and HIP to the ULID formats. Currently the proposed LISP protocol is very simple, but I expect it to grow considerably more complex once all the security issues are solved. So, to me, the biggest differences are in trust models and security. That, in turn, are hard to comment in detail at the moment, for two reasons: 1. There is no detailed spec for proxying SHIM6 and/or HIP 2. The LISP spec is missing the security details Now, based on my earlier work, starting from the late Homeless Mobile IPv6 proposal (which was killed due to security considerations), through MIPv6 security, HIP, and some aspects of SHIM6 security design, my gut feeling is that once security is added to LISP, we end up with a very similar design to current SHIM6 and HIP, with a four- way handshake that uses certain cryptographic bindings and return routability. But of course I may be completely wrong here; it may be easier to provide security in the network side, at least if you can assume S-BGP or similar. But then, can you assume that such a security framework would be there? Anyway, if I happen to be right in my security gut feeling, I don't see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP. Both HIP and SHIM6 are much more mature at the date that LISP. If/when proxying is added to them, they should be able to allow similar network-based implementation and TE characteristics that LISP do. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 15 22:22:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHteS-0007Or-BR; Thu, 15 Feb 2007 22:20:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHteS-0007Om-0w for ram@iab.org; Thu, 15 Feb 2007 22:20:48 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHteQ-000173-F9 for ram@iab.org; Thu, 15 Feb 2007 22:20:48 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 15 Feb 2007 19:20:46 -0800 X-IronPort-AV: i="4.14,179,1170662400"; d="scan'208"; a="361212523:sNHT55616692" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1G3Kjwi005533; Thu, 15 Feb 2007 19:20:45 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l1G3KfUw025595; Thu, 15 Feb 2007 19:20:45 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 19:20:41 -0800 Received: from [192.168.0.4] ([10.21.96.245]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 15 Feb 2007 19:20:40 -0800 In-Reply-To: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Thu, 15 Feb 2007 19:20:41 -0800 To: Pekka Nikander X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Feb 2007 03:20:40.0756 (UTC) FILETIME=[6F8A0F40:01C75179] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6641; t=1171596045; x=1172460045; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=hj/8PhQs0y78hk2AqtzZw+26eZMzKDz4qEat4KVHJ7s=; b=TYBihA3LYpCUB64M8VD42BrF4M47tFITJNcbn0P0MMntdk1CZkMbLoJruBdbrG1yiXSg88vj 6WefEgCOXnTYt+SuidBTYsKKGpafC7lAFmjKtrRc9jt0LDLuyI10OrYJ; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I finally had time to properly read draft-farinacci-lisp-00. To > me, it is intriguing work from deployment and implementation point > of view. However, it also seems to bear wider Thanks for reading and commenting on the draft Pekka. > architectural similarities to what would be proxied SHIM6 or HIP, > or any other proxied host-based identifier/locator split architecture. It's interesting you say that, but here is an observation. It is certainly true that LISP could be performed in the hosts, but it would be unlikely that SHIM6 or HIP would be in the network. The point of LISP, is that it stays in the network so there are absolutely no changes to the host implementations. I'm sure you didn't miss this but it should be emphasized. I think it will take far less time to widely deploy LISP then it would either SHIM6 or HIP. Just less things to touch as well as LISP being a much simpler solution. > From an architectural point of view, I would divide the proposed > mechanism into four different aspects: > > 1. Placement of the identifier / locator mapping function > 2. Encapsulating of data packets > 3. State creating between mapping points, i.e., the "protocol" > 4. Trust models and security mechanisms Yep, but I guess this is true for all candidate solutions. You need to say more to differentiate them. > Continuing from this architectural viewpoint, at least to me, the > main feature of LISP is to place the identifier / locator mapping > function into separate boxes in the network, not at the hosts. Correct. > However, as I tied to outline in draft-nikander-ram-generix- > proxying-00.txt, also host-based approaches allow such placement by > "stretching" the stack into a wire. In the case of the Yes, any proposal can be tweaked to look like other ones. The gem in the rough is what the original intention was for the design (and actually sticking to it). > EIDs being routable (as for LISP 1 or 1.5), there is also > considerable freedom in placing the proxies in the network; see > Section 7 of the draft. Yep, because you don't want to change the numerous intra-domain routers. LISP is also trying to optimize on the number of changes to routers as well. Even the amount of code in the ones that will do LISP. To be able to get to a solution that bears fruit relatively soon, we must have incremental deployment. And the less changes you have to make, the faster and easier we will get to the fruit. > ---------+---------------+----------+------------------ > LISP | IP tunnel | ICMP/new | not defined yet > SHIM6 | Context tag | SHIM6 | HBA / CGA + RR > HIP | IPsec ESP | HIP BE | ORCHID + RR > > Looking at the details, I don't see any fundamental differences in > encapsulation. IP Encapsulation shouldn't be a subject of debate. It certainly isn't the interesting part and if you had n proposals with n encapsulations that would be problematic. We should just pick one that is already supported. > tunnelling could be easily used for SHIM6 and HIP, too. Basically, > what SHIM6 and HIP provide are optimised tunnelling, i.e., headers > that are optimised to carry the minimum amount of information > needed so that the receiving end (ETR in LISP terminology) can re- > create the original packet. If tunnelling (with all its known > drawbacks) is considered to be a better encapsulation method that > what is currently defined for SHIM6 or HIP, it would be a no- > brainer to adjust SHIM6 and/or HIP accordingly. Hmm, I don't see this. And you said it, the devil is in the details. So I have no idea what you mean by adjusting SHIM6/HIP accordingly. You mean accordingly to LISP? It is true you can run LISP in the host and doing so requires host changes. So the important aspects of the design is *just not the architecture* but all the things that need to happen to get it deployed, working, and easy to manage. > 2. The LISP spec is missing the security details And do you know why? Because security in and of itself is not hard, it's that the security mechanism that are in the toolbox are way too heavy weight. I have talked to 100s of people in the last 3 months about how to secure LISP, and even the security experts can't give me a simple way to do what I want to do. The ISP community is saying "don't put any in because no matter how hard you try it will be too complex to manage". I get comments like: "if you put security in LISP, do it without a PKI" "try to do it with no state and no 3-way handshake" "don't depend on a third-party" "we really don't need it at all" "worry about it later, give me bits to play with first" So that doesn't leave very many tools left in the toolbox. And shared symmetric configured keys is a non-starter. We do that for routing protocols because it is easy and localized to a subnet. > Now, based on my earlier work, starting from the late Homeless > Mobile IPv6 proposal (which was killed due to security > considerations), through MIPv6 security, HIP, and some aspects of > SHIM6 security design, my gut feeling is that once security is > added to LISP, we end up with a very similar design to current > SHIM6 and HIP, with a four-way handshake that uses certain Ha ha, you are probably right. Hence why we didn't include it in the -00 draft. But the authors don't want security to kill the draft. We want to get prototype deployment experience so we can learn much more about the problem then just talking about it. We are trying to figure something for the -01 draft though. > cryptographic bindings and return routability. But of course I may > be completely wrong here; it may be easier to provide security in > the network side, at least if you can assume S-BGP or similar. But > then, can you assume that such a security framework would be there? S-BGP is too heavy-weight as well, in my opinion. > Anyway, if I happen to be right in my security gut feeling, I don't > see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP. Both > HIP and SHIM6 are much more mature at the date that LISP. If/when > proxying is added to them, they should be able to allow similar > network-based implementation and TE characteristics that LISP do. I believe LISP with security can get deployed sooner than if SHIM6/ HIP did not have security. Just less things to touch. > --Pekka Nikander Thanks again, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 15 22:36:18 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHtt6-0002Cj-T1; Thu, 15 Feb 2007 22:35:56 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHtt5-0002CA-0c for ram@ietf.org; Thu, 15 Feb 2007 22:35:55 -0500 Received: from smtp5-g19.free.fr ([212.27.42.35]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHtt2-0003i3-GW for ram@ietf.org; Thu, 15 Feb 2007 22:35:54 -0500 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp5-g19.free.fr (Postfix) with ESMTP id A6467279E7 for ; Fri, 16 Feb 2007 04:35:41 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Feb 2007 04:35:44 +0100 To: ram@ietf.org From: JFC Morfin Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070216033541.A6467279E7@smtp5-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org LISP is intended for IPv4 as well and supports multiple encapsulation for unlimited successive addressing capacity. As a selfish user my main need is not many more network address (I have already mine) it is stability, simplicity in installation and a very large number of standardizable local addresses (plug and play, access grids, etc) to best manage my single IP address (and I can can give all the other back, so I am not as selfish as you thought first). I understand that LISP gives this to me through successive possibility of addressing encapsulation. I see here a good chance to promote NATs to the point to get rid of them in transforming them into smart standalone gateways exchanges, speaking LISP with the global network and IPv4 or IPv6 or other environment with the local network? Not to change anything in the existing systems, I proposed to structure the IPv6 address payload to split the three address layers, and supposed that an 'internat IPv8' could be a grassroots intermediary patch. LISP seems to elegantly address all this. jfc On 09:34 15/02/2007, Pekka Nikander said: >I finally had time to properly read draft-farinacci-lisp-00. To me, >it is intriguing work from deployment and implementation point of >view. However, it also seems to bear wider architectural >similarities to what would be proxied SHIM6 or HIP, or any other >proxied host-based identifier/locator split architecture. > > From an architectural point of view, I would divide the proposed >mechanism into four different aspects: > > 1. Placement of the identifier / locator mapping function > 2. Encapsulating of data packets > 3. State creating between mapping points, i.e., the "protocol" > 4. Trust models and security mechanisms > >Continuing from this architectural viewpoint, at least to me, the >main feature of LISP is to place the identifier / locator mapping >function into separate boxes in the network, not at the hosts. >However, as I tied to outline in draft-nikander-ram-generix- >proxying-00.txt, also host-based approaches allow such placement by >"stretching" the stack into a wire. In the case of the EIDs being >routable (as for LISP 1 or 1.5), there is also considerable freedom >in placing the proxies in the network; see Section 7 of the draft. > >Considering the other aspects, LISP and any SHIM6/HIP based proxied >approach are pretty similar. Both encapsulate the data packets >somehow, at least conceptually*). Both need to create appropriate >mapping state between the mapping points, and resynchronise the state >in the case of mobility or state loss. Both need some mechanism for >securing against traffic stealing, black-holing, and flooding. > >*) When ESP is used with HIP, actually no explicit encapsulation is >needed since the ESP SPI can be used for demultiplexing the traffic >at the decapsulating end. > >The differences are in details. The following table attempts to >capture the crux. > >Approach | Encapsulation | Protocol | Security >---------+---------------+----------+------------------ >LISP | IP tunnel | ICMP/new | not defined yet >SHIM6 | Context tag | SHIM6 | HBA / CGA + RR >HIP | IPsec ESP | HIP BE | ORCHID + RR > >Looking at the details, I don't see any fundamental differences in >encapsulation. IP tunnelling could be easily used for SHIM6 and HIP, >too. Basically, what SHIM6 and HIP provide are optimised tunnelling, >i.e., headers that are optimised to carry the minimum amount of >information needed so that the receiving end (ETR in LISP >terminology) can re-create the original packet. If tunnelling (with >all its known drawbacks) is considered to be a better encapsulation >method that what is currently defined for SHIM6 or HIP, it would be a >no-brainer to adjust SHIM6 and/or HIP accordingly. > >Looking at the protocols, SHIM6 and HIP base exchange carry known >similarities; the SHIM6 protocol was inspired by HIP. The biggest >advances of SHIM6 to HIP are its ability for late binding and lighter >cryptographic operations. However, the LHIP proposal provides >similar properties for HIP too, rendering the fundamental differences >between SHIM6 and HIP to the ULID formats. Currently the proposed >LISP protocol is very simple, but I expect it to grow considerably >more complex once all the security issues are solved. > >So, to me, the biggest differences are in trust models and security. >That, in turn, are hard to comment in detail at the moment, for two >reasons: > > 1. There is no detailed spec for proxying SHIM6 and/or HIP > > 2. The LISP spec is missing the security details > > >Now, based on my earlier work, starting from the late Homeless Mobile >IPv6 proposal (which was killed due to security considerations), >through MIPv6 security, HIP, and some aspects of SHIM6 security >design, my gut feeling is that once security is added to LISP, we end >up with a very similar design to current SHIM6 and HIP, with a four- >way handshake that uses certain cryptographic bindings and return >routability. But of course I may be completely wrong here; it may be >easier to provide security in the network side, at least if you can >assume S-BGP or similar. But then, can you assume that such a >security framework would be there? > >Anyway, if I happen to be right in my security gut feeling, I don't >see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP. Both >HIP and SHIM6 are much more mature at the date that LISP. If/when >proxying is added to them, they should be able to allow similar >network-based implementation and TE characteristics that LISP do. > >--Pekka Nikander > > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 16 02:30:42 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxVe-0006y3-7T; Fri, 16 Feb 2007 02:27:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHxVc-0006xp-9i for ram@iab.org; Fri, 16 Feb 2007 02:27:56 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHxVb-0006uS-Jq for ram@iab.org; Fri, 16 Feb 2007 02:27:56 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 97B1C212D30; Fri, 16 Feb 2007 09:27:49 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 2C16C212D1F; Fri, 16 Feb 2007 09:27:49 +0200 (EET) In-Reply-To: References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Fri, 16 Feb 2007 09:27:39 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: 963faf56c3a5b6715f0b71b66181e01a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, On 16 Feb 2007, at 05:20, Dino Farinacci wrote: >> architectural similarities to what would be proxied SHIM6 or HIP, >> or any other proxied host-based identifier/locator split >> architecture. > > It's interesting you say that, but here is an observation. It is > certainly true that LISP could be performed in the hosts, but it > would be unlikely that SHIM6 or HIP would be in the network. The > point of LISP, is that it stays in the network so there are > absolutely no changes to the host implementations. As I try to argue in the generix draft, and as I alleged later in my previous message, I do believe that it is perfectly reasonable to implement SHIM6 or even HIP in the network, requiring no changes to the host implementations. As I argued in the arch-d list already earlier, I do see here two almost orthogonal (i.e. mutually independent) dimensions: 1. A "vertical" one, i.e., where in the stack the we do the mapping. Upper or lower, layering wise. To me, this is more architectural then the other one. 2. A "horizontal" one, i.e., where in the host-network dimension. In core, edge, host. To me, this one is more an implementation dimension than the "vertical" dimension. I say that these are _almost_ orthogonal since the lower in the stack the mapping is done, the easier it is to apply the mechanism deep in the network. However, I don't consider LISP, SHIM6, and HIP being that different in this sense. "Vertically", they are almost at the same location, perhaps LISP being at the lowest and HIP at the highest position in the stack. However, I believe the difference is small enough so that it does not really limit the implementation options: I do believe that SHIM6 (and perhaps also HIP) could be implemented deep in the network, similar to LISP 1. We did a limited demonstration of that (with HIP) over two years ago, in a real but specific (3GPP) environment. So, I have some foundation for my belief, even though I have to admit that AFAIK nobody has worked out the details for the fully generic case. > I'm sure you didn't miss this but it should be emphasized. I think > it will take far less time to widely deploy LISP then it would > either SHIM6 or HIP. If we were to implement SHIM6 or HIP in the hosts, I would agree. But with proxied SHIM6 or HIP, I don't see any necessary differences. > Just less things to touch as well as LISP being a much simpler > solution. I don't believe that LISP would end up simpler, at least compared to SHIM6, in the end of the day when all details have been worked out. As you know, each new proposal is initially simpler than the existing ones, and grows more complex (than it initially is) as the details are fleshed out. If we measure the complexity in terms of LoC (in the C programming language), I believe that all these three proposals add the order of 10000 LoC into realistic implementations. We have reported those numbers for HIP for a number of years now; I haven't seen numbers for SHIM6 but I believe they are pretty similar; maybe slightly smaller than for HIP, but not much. LISP might get along with slightly less (e.g. 3000-4000 LoC once the security is there) due to employing existing tunnelling, but I wouldn't expect any orders of magnitude smaller complexity. But again, I may be completely wrong here; I'm very interested in seeing your numbers once you've got the prototype ready. So, to me, the current "simplicity" of LISP (compared to SHIM6 and HIP) is a result of two factors: First, it is still at the idea level, without sufficient details. Second, it is using constructions that are familiar to the operator community (such as tunnelling and ICMP) while the other proposals use more specialised (and more optimised!) constructions. As I argued above, I don't believe there will be any significant complexity differences in terms of implementation or specification complexity, once all the details will be there. And, as I argue separately (both above and below), I don't believe there will be any significant differences in the terms of deployment complexity, either. >> However, as I tied to outline in draft-nikander-ram-generix- >> proxying-00.txt, also host-based approaches allow such placement >> by "stretching" the stack into a wire. In the case of the > > Yes, any proposal can be tweaked to look like other ones. The gem > in the rough is what the original intention was for the design (and > actually sticking to it). I think I have to strongly disagree here. I don't believe the question is about tweaking. I believe that the question is about the implementation ("horizontal") dimension rather than the architectural ("vertical") dimension. To me, the real differences lie in security constructions, and there in the underlying trust model, and in the identifiers. In LISP, the identifier differences lead to your very nice LISP 1, 1.5, 2, 3 genera construction, which I appreciate very much. It is _very_ nicely worked out. But a similar set of identifier structures can be applied also to SHIM6 (which is at level 1 currently) and to HIP (which is at level 1.5 or 2 currently). >> EIDs being routable (as for LISP 1 or 1.5), there is also >> considerable freedom in placing the proxies in the network; see >> Section 7 of the draft. > > Yep, because you don't want to change the numerous intra-domain > routers. LISP is also trying to optimize on the number of changes > to routers as well. Even the amount of code in the ones that will > do LISP. I don't see any real difference here between LISP and SHIM6 (and maybe HIP), since the same identifier genera (1, 1.5, 2, 3) can also be applied in all two (or three) cases. >> If tunnelling (with all its known drawbacks) is considered to be a >> better encapsulation method that what is currently defined for >> SHIM6 or HIP, it would be a no-brainer to adjust SHIM6 and/or HIP >> accordingly. > > Hmm, I don't see this. And you said it, the devil is in the > details. So I have no idea what you mean by adjusting SHIM6/HIP > accordingly. You mean accordingly to LISP? Sorry for being obscure. What I meant is that if we think that tunnelling is a better method for encapsulation than the SHIM6 context tag or the encapsulation flexibility in HIP, both SHIM6 and HIP could be easily adjusted to use tunnelling. > [W.r.t LISP security design] I get comments like: Let me try those for SHIM6/HIP: > "if you put security in LISP, do it without a PKI" Check for both SHIM6 and HIP. > "try to do it with no state and no 3-way handshake" I believe that is pretty impossible, or alternatively would increase the packet size to an unbearable level. For an old paper on the topic (not addressing it directly but laying some theoretical foundation), consider our 1997 paper on "stateless connections". (Sorry, I'm offline while writing this but it can be found on my publications page.) > "don't depend on a third-party" Check for both SHIM6 and HIP. > "we really don't need it at all" Now, that is an interesting argument. It may be true, depending on your trust model. Certainly, a single ISP or a mutually fully trusting ISP coalition could deploy a LISP-like structure without any security. But then, what would be the functional difference from using properly configured, dynamic MPLS tunnels? > "worry about it later, give me bits to play with first" That is the attitude that, IMHO, has brought us with the current DDoS problems. > I believe LISP with security can get deployed sooner than if SHIM6/ > HIP did not have security. Just less things to touch. I think this is the crux of our disagreement. I appreciate your opinion, but I don't believe it to be _necessarily_ true. But then, someone needs to figure out exactly how to proxy SHIM6 or HIP in the generic case. There may be details there that I cannot foresee and make such proxying approach much more complex than I currently think. But then, as I said, I believe adding security to LISP makes it clearly more complex than it currently looks like. The other part of the argument would be the other potential architectural benefits from the different approaches. That we haven't touched yet. But I think it also warrants distinct messages instead of burying it here. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 16 10:59:27 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HI5Rk-0003Zn-Ft; Fri, 16 Feb 2007 10:56:28 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HHsfx-00027K-Mv for ram@ietf.org; Thu, 15 Feb 2007 21:18:17 -0500 Received: from smtp2-g19.free.fr ([212.27.42.28]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HHsfw-0000eS-RN for ram@ietf.org; Thu, 15 Feb 2007 21:18:17 -0500 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp2-g19.free.fr (Postfix) with ESMTP id 1DE157D09; Fri, 16 Feb 2007 03:18:06 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Feb 2007 02:49:52 +0100 To: Pekka Nikander From: JFCM Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 In-Reply-To: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> Mime-Version: 1.0 Message-Id: <20070216021806.1DE157D09@smtp2-g19.free.fr> X-Spam-Score: 0.3 (/) X-Scan-Signature: 40161b1d86420e0807d771943d981d25 X-Mailman-Approved-At: Fri, 16 Feb 2007 10:56:27 -0500 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1230925211==" Errors-To: ram-bounces@iab.org --===============1230925211== Content-Type: multipart/alternative; boundary="=====================_26977703==.ALT" --=====================_26977703==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed LISP is intended for IPv4 as well and supports multiple encapsulation for unlimited successive addressing capacity. As a selfish user my main need is not many more network address (I have already mine) it is stability, simplicity in installation and a very large number of standardizable local addresses (plug and play, access grids, etc). I feel that LISP gives this to me through successive possibility of addressing encapsulation. I see here a good chance to promote NATs to the point to get rid of them in transforming them into smart standalone gateways exchanges, speaking LISP with the global network and IPv4 or IPv6 or other environment with the local network? Not to change anything in the existing system, I proposed to structure the IPv6 address payload and supposed that an internat IPv8 could be a grassroots intermediary patch. LISP seems to elegantly address all this, including you say an interoperability with SHIM6 and HIP.? jfc On 09:34 15/02/2007, Pekka Nikander said: >I finally had time to properly read draft-farinacci-lisp-00. To me, >it is intriguing work from deployment and implementation point of >view. However, it also seems to bear wider architectural >similarities to what would be proxied SHIM6 or HIP, or any other >proxied host-based identifier/locator split architecture. > > From an architectural point of view, I would divide the proposed >mechanism into four different aspects: > > 1. Placement of the identifier / locator mapping function > 2. Encapsulating of data packets > 3. State creating between mapping points, i.e., the "protocol" > 4. Trust models and security mechanisms > >Continuing from this architectural viewpoint, at least to me, the >main feature of LISP is to place the identifier / locator mapping >function into separate boxes in the network, not at the hosts. >However, as I tied to outline in draft-nikander-ram-generix- >proxying-00.txt, also host-based approaches allow such placement by >"stretching" the stack into a wire. In the case of the EIDs being >routable (as for LISP 1 or 1.5), there is also considerable freedom >in placing the proxies in the network; see Section 7 of the draft. > >Considering the other aspects, LISP and any SHIM6/HIP based proxied >approach are pretty similar. Both encapsulate the data packets >somehow, at least conceptually*). Both need to create appropriate >mapping state between the mapping points, and resynchronise the state >in the case of mobility or state loss. Both need some mechanism for >securing against traffic stealing, black-holing, and flooding. > >*) When ESP is used with HIP, actually no explicit encapsulation is >needed since the ESP SPI can be used for demultiplexing the traffic >at the decapsulating end. > >The differences are in details. The following table attempts to >capture the crux. > >Approach | Encapsulation | Protocol | Security >---------+---------------+----------+------------------ >LISP | IP tunnel | ICMP/new | not defined yet >SHIM6 | Context tag | SHIM6 | HBA / CGA + RR >HIP | IPsec ESP | HIP BE | ORCHID + RR > >Looking at the details, I don't see any fundamental differences in >encapsulation. IP tunnelling could be easily used for SHIM6 and HIP, >too. Basically, what SHIM6 and HIP provide are optimised tunnelling, >i.e., headers that are optimised to carry the minimum amount of >information needed so that the receiving end (ETR in LISP >terminology) can re-create the original packet. If tunnelling (with >all its known drawbacks) is considered to be a better encapsulation >method that what is currently defined for SHIM6 or HIP, it would be a >no-brainer to adjust SHIM6 and/or HIP accordingly. > >Looking at the protocols, SHIM6 and HIP base exchange carry known >similarities; the SHIM6 protocol was inspired by HIP. The biggest >advances of SHIM6 to HIP are its ability for late binding and lighter >cryptographic operations. However, the LHIP proposal provides >similar properties for HIP too, rendering the fundamental differences >between SHIM6 and HIP to the ULID formats. Currently the proposed >LISP protocol is very simple, but I expect it to grow considerably >more complex once all the security issues are solved. > >So, to me, the biggest differences are in trust models and security. >That, in turn, are hard to comment in detail at the moment, for two >reasons: > > 1. There is no detailed spec for proxying SHIM6 and/or HIP > > 2. The LISP spec is missing the security details > > >Now, based on my earlier work, starting from the late Homeless Mobile >IPv6 proposal (which was killed due to security considerations), >through MIPv6 security, HIP, and some aspects of SHIM6 security >design, my gut feeling is that once security is added to LISP, we end >up with a very similar design to current SHIM6 and HIP, with a four- >way handshake that uses certain cryptographic bindings and return >routability. But of course I may be completely wrong here; it may be >easier to provide security in the network side, at least if you can >assume S-BGP or similar. But then, can you assume that such a >security framework would be there? > >Anyway, if I happen to be right in my security gut feeling, I don't >see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP. Both >HIP and SHIM6 are much more mature at the date that LISP. If/when >proxying is added to them, they should be able to allow similar >network-based implementation and TE characteristics that LISP do. > >--Pekka Nikander > > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram --=====================_26977703==.ALT Content-Type: text/html; charset="us-ascii" LISP is intended for IPv4 as well and supports multiple encapsulation for unlimited successive addressing capacity.

As a selfish user my main need is not many more network address (I have already mine) it is stability, simplicity in installation and a very large number of standardizable local addresses (plug and play, access grids, etc). I feel that LISP gives this to me through successive possibility of  addressing encapsulation. I see here a good chance to promote NATs to the point to get rid of them in transforming them into smart standalone gateways exchanges, speaking LISP with the global network and IPv4 or IPv6 or other environment with the local network?

Not to change anything in the existing system, I proposed to structure the IPv6 address payload and supposed that an internat IPv8 could be a grassroots intermediary patch. LISP seems to elegantly address all this, including you say an interoperability with SHIM6 and HIP.?

jfc


On 09:34 15/02/2007, Pekka Nikander said:
I finally had time to properly read draft-farinacci-lisp-00.  To me, 
it is intriguing work from deployment and implementation point of 
view.  However, it also seems to bear wider architectural 
similarities to what would be proxied SHIM6 or HIP, or any other 
proxied host-based identifier/locator split architecture.

From an architectural point of view, I would divide the proposed 
mechanism into four different aspects:

  1. Placement of the identifier / locator mapping function
  2. Encapsulating of data packets
  3. State creating between mapping points, i.e., the "protocol"
  4. Trust models and security mechanisms

Continuing from this architectural viewpoint, at least to me, the 
main feature of LISP is to place the identifier / locator mapping 
function into separate boxes in the network, not at the hosts.  
However, as I tied to outline in draft-nikander-ram-generix- proxying-00.txt, also host-based approaches allow such placement by 
"stretching" the stack into a wire.  In the case of the EIDs being 
routable (as for LISP 1 or 1.5), there is also considerable freedom 
in placing the proxies in the network; see Section 7 of the draft.

Considering the other aspects, LISP and any SHIM6/HIP based proxied 
approach are pretty similar.  Both encapsulate the data packets 
somehow, at least conceptually*).  Both need to create appropriate 
mapping state between the mapping points, and resynchronise the state 
in the case of mobility or state loss.  Both need some mechanism for 
securing against traffic stealing, black-holing, and flooding.

*) When ESP is used with HIP, actually no explicit encapsulation is 
needed since the ESP SPI can be used for demultiplexing the traffic 
at the decapsulating end.

The differences are in details.  The following table attempts to 
capture the crux.

Approach | Encapsulation | Protocol | Security
---------+---------------+----------+------------------
LISP     | IP tunnel     | ICMP/new | not defined yet
SHIM6    | Context tag   | SHIM6    | HBA / CGA + RR
HIP      | IPsec ESP     | HIP BE   | ORCHID + RR

Looking at the details, I don't see any fundamental differences in 
encapsulation.  IP tunnelling could be easily used for SHIM6 and HIP, 
too.  Basically, what SHIM6 and HIP provide are optimised tunnelling, 
i.e., headers that are optimised to carry the minimum amount of 
information needed so that the receiving end (ETR in LISP 
terminology) can re-create the original packet.  If tunnelling (with 
all its known drawbacks) is considered to be a better encapsulation 
method that what is currently defined for SHIM6 or HIP, it would be a 
no-brainer to adjust SHIM6 and/or HIP accordingly.

Looking at the protocols, SHIM6 and HIP base exchange carry known 
similarities; the SHIM6 protocol was inspired by HIP.  The biggest 
advances of SHIM6 to HIP are its ability for late binding and lighter 
cryptographic operations.  However, the LHIP proposal provides 
similar properties for HIP too, rendering the fundamental differences 
between SHIM6 and HIP to the ULID formats.  Currently the proposed 
LISP protocol is very simple, but I expect it to grow considerably 
more complex once all the security issues are solved.

So, to me, the biggest differences are in trust models and security.  
That, in turn, are hard to comment in detail at the moment, for two 
reasons:

 1. There is no detailed spec for proxying SHIM6 and/or HIP

 2. The LISP spec is missing the security details


Now, based on my earlier work, starting from the late Homeless Mobile 
IPv6 proposal (which was killed due to security considerations), 
through MIPv6 security, HIP, and some aspects of SHIM6 security 
design, my gut feeling is that once security is added to LISP, we end 
up with a very similar design to current SHIM6 and HIP, with a four- way handshake that uses certain cryptographic bindings and return 
routability.  But of course I may be completely wrong here; it may be 
easier to provide security in the network side, at least if you can 
assume S-BGP or similar.  But then, can you assume that such a 
security framework would be there?

Anyway, if I happen to be right in my security gut feeling, I don't 
see any real benefits in LISP w.r.t. to proxied SHIM6 or HIP.  Both 
HIP and SHIM6 are much more mature at the date that LISP.  If/when 
proxying is added to them, they should be able to allow similar 
network-based implementation and TE characteristics that LISP do.

--Pekka Nikander


_______________________________________________
RAM mailing list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
--=====================_26977703==.ALT-- --===============1230925211== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1230925211==-- From ram-bounces@iab.org Sat Feb 17 11:13:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIS8P-0003NM-EV; Sat, 17 Feb 2007 11:10:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HIS8O-0003N7-8b for ram@iab.org; Sat, 17 Feb 2007 11:10:00 -0500 Received: from tayrelbas04.tay.hp.com ([161.114.80.247]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HIS8J-000859-O3 for ram@iab.org; Sat, 17 Feb 2007 11:10:00 -0500 Received: from tayexg12.americas.cpqcorp.net (tayexg12.americas.cpqcorp.net [16.103.130.127]) by tayrelbas04.tay.hp.com (Postfix) with ESMTP id 4C18634072; Sat, 17 Feb 2007 11:09:55 -0500 (EST) Received: from tayexc14.americas.cpqcorp.net ([16.103.130.45]) by tayexg12.americas.cpqcorp.net with Microsoft SMTPSVC(6.0.3790.1830); Sat, 17 Feb 2007 11:09:55 -0500 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Sat, 17 Feb 2007 11:09:54 -0500 Message-ID: <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> In-Reply-To: <19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-index: AcdRnDXSuanDiwrqTGWT1+qmNZZm1QBCatuA References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com> <19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> From: "Bound, Jim" To: "Pekka Nikander" , "Dino Farinacci" X-OriginalArrivalTime: 17 Feb 2007 16:09:55.0111 (UTC) FILETIME=[10177B70:01C752AE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >From below. LISP has plenty of details for me to get going here. It is simple and will work, the authors all have implemented specs and architecture that works in practice running today and not in theory. It also does not preclude further research and debates on HIP, SHIM6, etc. The issues you state below are all theoretical abstractions, and interesting and I now believe should be in the IRTF. LISP is a reality sandwich presented that will solve in my view the RAM ID from the IAB and add much other value and avoid hosts for "now" messing with ID / Loc split, which we are not going to solve in the year 2007 on this list IMHO. Best, /jim > -----Original Message----- > From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com]=20 > Sent: Friday, February 16, 2007 2:28 AM > To: Dino Farinacci > Cc: ram@iab.org > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > Hi Dino, >=20 > On 16 Feb 2007, at 05:20, Dino Farinacci wrote: > >> architectural similarities to what would be proxied SHIM6=20 > or HIP, or=20 > >> any other proxied host-based identifier/locator split architecture. > > > > It's interesting you say that, but here is an observation. It is=20 > > certainly true that LISP could be performed in the hosts,=20 > but it would=20 > > be unlikely that SHIM6 or HIP would be in the network. The point of=20 > > LISP, is that it stays in the network so there are absolutely no=20 > > changes to the host implementations. >=20 > As I try to argue in the generix draft, and as I alleged=20 > later in my previous message, I do believe that it is=20 > perfectly reasonable to implement SHIM6 or even HIP in the=20 > network, requiring no changes to the host implementations. =20 > As I argued in the arch-d list already earlier, I do see here=20 > two almost orthogonal (i.e. mutually > independent) dimensions: >=20 > 1. A "vertical" one, i.e., where in the stack the we do the=20 > mapping. =20 > Upper or lower, layering wise. To me, this is more=20 > architectural then the other one. >=20 > 2. A "horizontal" one, i.e., where in the host-network=20 > dimension. In core, edge, host. To me, this one is more an=20 > implementation dimension than the "vertical" dimension. >=20 > I say that these are _almost_ orthogonal since the lower in=20 > the stack the mapping is done, the easier it is to apply the=20 > mechanism deep in the network. However, I don't consider=20 > LISP, SHIM6, and HIP being that different in this sense. =20 > "Vertically", they are almost at the same location, perhaps=20 > LISP being at the lowest and HIP at the highest position in=20 > the stack. However, I believe the difference is small enough=20 > so that it does not really limit the implementation > options: I do believe that SHIM6 (and perhaps also HIP) could=20 > be implemented deep in the network, similar to LISP 1. We=20 > did a limited demonstration of that (with HIP) over two years=20 > ago, in a real but specific (3GPP) environment. So, I have=20 > some foundation for my belief, even though I have to admit=20 > that AFAIK nobody has worked out the details for the fully=20 > generic case. >=20 > > I'm sure you didn't miss this but it should be emphasized.=20 > I think it=20 > > will take far less time to widely deploy LISP then it would either=20 > > SHIM6 or HIP. >=20 > If we were to implement SHIM6 or HIP in the hosts, I would agree. =20 > But with proxied SHIM6 or HIP, I don't see any necessary differences. >=20 > > Just less things to touch as well as LISP being a much simpler=20 > > solution. >=20 > I don't believe that LISP would end up simpler, at least compared to =20 > SHIM6, in the end of the day when all details have been worked out. =20 > As you know, each new proposal is initially simpler than the=20 > existing ones, and grows more complex (than it initially is)=20 > as the details are fleshed out. >=20 > If we measure the complexity in terms of LoC (in the C=20 > programming language), I believe that all these three=20 > proposals add the order of 10000 LoC into realistic=20 > implementations. We have reported those numbers for HIP for=20 > a number of years now; I haven't seen numbers for > SHIM6 but I believe they are pretty similar; maybe slightly=20 > smaller than for HIP, but not much. LISP might get along=20 > with slightly less (e.g. 3000-4000 LoC once the security is=20 > there) due to employing existing tunnelling, but I wouldn't=20 > expect any orders of magnitude smaller complexity. But=20 > again, I may be completely wrong here; I'm very interested in=20 > seeing your numbers once you've got the prototype ready. >=20 > So, to me, the current "simplicity" of LISP (compared to SHIM6 and > HIP) is a result of two factors: First, it is still at the=20 > idea level, without sufficient details. Second, it is using=20 > constructions that are familiar to the operator community=20 > (such as tunnelling and > ICMP) while the other proposals use more specialised (and more > optimised!) constructions. As I argued above, I don't=20 > believe there will be any significant complexity differences=20 > in terms of implementation or specification complexity, once=20 > all the details will be there. And, as I argue separately=20 > (both above and below), I don't believe there will be any=20 > significant differences in the terms of deployment complexity, either. >=20 >=20 > upon. In many cases I fully agree with you, e.g., what comes=20 > to the importance of deployment.> >=20 > >> However, as I tied to outline in draft-nikander-ram-generix-=20 > >> proxying-00.txt, also host-based approaches allow such=20 > placement by=20 > >> "stretching" the stack into a wire. In the case of the > > > > Yes, any proposal can be tweaked to look like other ones.=20 > The gem in=20 > > the rough is what the original intention was for the design (and=20 > > actually sticking to it). >=20 > I think I have to strongly disagree here. I don't believe=20 > the question is about tweaking. I believe that the question=20 > is about the implementation ("horizontal") dimension rather=20 > than the architectural > ("vertical") dimension. To me, the real differences lie in=20 > security constructions, and there in the underlying trust=20 > model, and in the identifiers. In LISP, the identifier=20 > differences lead to your very nice LISP 1, 1.5, 2, 3 genera=20 > construction, which I appreciate very much. It is _very_=20 > nicely worked out. But a similar set of identifier=20 > structures can be applied also to SHIM6 (which is at level > 1 currently) and to HIP (which is at level 1.5 or 2 currently). >=20 > >> EIDs being routable (as for LISP 1 or 1.5), there is also=20 > >> considerable freedom in placing the proxies in the network; see=20 > >> Section 7 of the draft. > > > > Yep, because you don't want to change the numerous intra-domain=20 > > routers. LISP is also trying to optimize on the number of=20 > changes to=20 > > routers as well. Even the amount of code in the ones that will do=20 > > LISP. >=20 > I don't see any real difference here between LISP and SHIM6=20 > (and maybe HIP), since the same identifier genera (1, 1.5, 2,=20 > 3) can also be applied in all two (or three) cases. >=20 > >> If tunnelling (with all its known drawbacks) is considered to be a=20 > >> better encapsulation method that what is currently defined for > >> SHIM6 or HIP, it would be a no-brainer to adjust SHIM6 and/or HIP=20 > >> accordingly. > > > > Hmm, I don't see this. And you said it, the devil is in the=20 > details.=20 > > So I have no idea what you mean by adjusting SHIM6/HIP accordingly.=20 > > You mean accordingly to LISP? >=20 > Sorry for being obscure. What I meant is that if we think=20 > that tunnelling is a better method for encapsulation than the=20 > SHIM6 context tag or the encapsulation flexibility in HIP,=20 > both SHIM6 and HIP could be easily adjusted to use tunnelling. >=20 >=20 > > [W.r.t LISP security design] I get comments like: >=20 > Let me try those for SHIM6/HIP: >=20 > > "if you put security in LISP, do it without a PKI" >=20 > Check for both SHIM6 and HIP. >=20 > > "try to do it with no state and no 3-way handshake" >=20 > I believe that is pretty impossible, or alternatively would=20 > increase the packet size to an unbearable level. For an old=20 > paper on the topic (not addressing it directly but laying=20 > some theoretical =20 > foundation), consider our 1997 paper on "stateless connections". =20 > (Sorry, I'm offline while writing this but it can be found on=20 > my publications page.) >=20 > > "don't depend on a third-party" >=20 > Check for both SHIM6 and HIP. >=20 > > "we really don't need it at all" >=20 > Now, that is an interesting argument. It may be true,=20 > depending on your trust model. Certainly, a single ISP or a=20 > mutually fully trusting ISP coalition could deploy a=20 > LISP-like structure without any security. But then, what=20 > would be the functional difference from using properly=20 > configured, dynamic MPLS tunnels? >=20 > > "worry about it later, give me bits to play with first" >=20 > That is the attitude that, IMHO, has brought us with the=20 > current DDoS problems. >=20 >=20 > > I believe LISP with security can get deployed sooner than if SHIM6/=20 > > HIP did not have security. Just less things to touch. >=20 > I think this is the crux of our disagreement. I appreciate=20 > your opinion, but I don't believe it to be _necessarily_=20 > true. But then, someone needs to figure out exactly how to=20 > proxy SHIM6 or HIP in the generic case. There may be details=20 > there that I cannot foresee and make such proxying approach=20 > much more complex than I currently think. But then, as I=20 > said, I believe adding security to LISP makes it clearly more=20 > complex than it currently looks like. >=20 > The other part of the argument would be the other potential=20 > architectural benefits from the different approaches. That=20 > we haven't touched yet. But I think it also warrants=20 > distinct messages instead of burying it here. >=20 > --Pekka Nikander >=20 >=20 > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 19 05:15:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ5W5-00050D-Gn; Mon, 19 Feb 2007 05:13:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJ5W4-0004zy-38 for ram@iab.org; Mon, 19 Feb 2007 05:13:04 -0500 Received: from smtp.nokia.com ([131.228.20.171] helo=mgw-ext12.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJ5W2-00073r-1u for ram@iab.org; Mon, 19 Feb 2007 05:13:04 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext12.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1JAAlDN026861; Mon, 19 Feb 2007 12:10:47 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 12:12:52 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Feb 2007 12:12:53 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 19 Feb 2007 12:12:50 +0200 Message-ID: In-Reply-To: <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdRnDXSuanDiwrqTGWT1+qmNZZm1QBCatuAAFlGAWA= References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> From: To: , , X-OriginalArrivalTime: 19 Feb 2007 10:12:53.0517 (UTC) FILETIME=[84A723D0:01C7540E] X-eXpurgate-Category: 1/0 X-eXpurgate-ID: 149371::070219121047-6750BBB0-48341E03/0-0/0-1 X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: c0aa019322dfce838bd8604f5a841b57 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org What bothers me about the LISP 1 proposal is that the IDs need be routable in the RLOC topology for it to work. It still requires renumbering when changing access providers. From this pespective the LISP2 seems more attractive. 2 variants of it are offered in the LISP2 presentation. It seems to me that combined use of the two variants would offer the good properties: default router should intercept DNS requests (which I do not believe will add additional latency) AND do lookup for destination EIDs that were used without a DNS query to begin with (with additional latency and dropping of first packets). In scaling the LISP it seems essential that the EIDs are also from an aggregateable space, so that same set of RLOCs could be shared for big number of EIDs without requiring EID specific entries in the caches. Also an interesting variant of the LISP (1.5?) would be to have the EID be routable, but not necessarily to the destination network, but to a kind of "EID/RLOC home agent" that could tunnel the packets to the destination network (that would then do the ICMP setup with the source network just like in LISP1). So instead of having separate routes to each and every destination network on the EID space, the network would have radically fewer number of routes in the EID space to "EID/RLOC home agent providers" (compare to Mobile IP virtual home networks), where the destination networks' edge routers would register their RLOCs. In essence the LISP1.5 would function like "core-proxied route optimized tunneled Mobile IP with virtual home networks". The kind of EIDs useful in this variant could have short prefixes and (with IPv6) plenty of bits left for e.g CGA (think 28 bits for prefix and 100 bits for crypto-id). Jarno >-----Original Message----- >From: ext Bound, Jim [mailto:Jim.Bound@hp.com]=20 >Sent: 17 February, 2007 18:10 >To: Pekka Nikander; Dino Farinacci >Cc: ram@iab.org >Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 > >>From below. LISP has plenty of details for me to get going here. It=20 >>is >simple and will work, the authors all have implemented specs=20 >and architecture that works in practice running today and not=20 >in theory. It also does not preclude further research and=20 >debates on HIP, SHIM6, etc. >The issues you state below are all theoretical abstractions,=20 >and interesting and I now believe should be in the IRTF. LISP=20 >is a reality sandwich presented that will solve in my view the=20 >RAM ID from the IAB and add much other value and avoid hosts=20 >for "now" messing with ID / Loc split, which we are not going=20 >to solve in the year 2007 on this list IMHO. > >Best, >/jim > >> -----Original Message----- >> From: Pekka Nikander [mailto:pekka.nikander@nomadiclab.com] >> Sent: Friday, February 16, 2007 2:28 AM >> To: Dino Farinacci >> Cc: ram@iab.org >> Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >>=20 >> Hi Dino, >>=20 >> On 16 Feb 2007, at 05:20, Dino Farinacci wrote: >> >> architectural similarities to what would be proxied SHIM6 >> or HIP, or >> >> any other proxied host-based identifier/locator split=20 >architecture. >> > >> > It's interesting you say that, but here is an observation. It is=20 >> > certainly true that LISP could be performed in the hosts, >> but it would >> > be unlikely that SHIM6 or HIP would be in the network. The=20 >point of=20 >> > LISP, is that it stays in the network so there are absolutely no=20 >> > changes to the host implementations. >>=20 >> As I try to argue in the generix draft, and as I alleged later in my=20 >> previous message, I do believe that it is perfectly reasonable to=20 >> implement SHIM6 or even HIP in the network, requiring no changes to=20 >> the host implementations. >> As I argued in the arch-d list already earlier, I do see here two=20 >> almost orthogonal (i.e. mutually >> independent) dimensions: >>=20 >> 1. A "vertical" one, i.e., where in the stack the we do the=20 >> mapping. =20 >> Upper or lower, layering wise. To me, this is more=20 >architectural then=20 >> the other one. >>=20 >> 2. A "horizontal" one, i.e., where in the host-network=20 >dimension. In=20 >> core, edge, host. To me, this one is more an implementation=20 >dimension=20 >> than the "vertical" dimension. >>=20 >> I say that these are _almost_ orthogonal since the lower in=20 >the stack=20 >> the mapping is done, the easier it is to apply the mechanism deep in=20 >> the network. However, I don't consider LISP, SHIM6, and HIP being=20 >> that different in this sense. >> "Vertically", they are almost at the same location, perhaps=20 >LISP being=20 >> at the lowest and HIP at the highest position in the stack. =20 >However,=20 >> I believe the difference is small enough so that it does not really=20 >> limit the implementation >> options: I do believe that SHIM6 (and perhaps also HIP) could be=20 >> implemented deep in the network, similar to LISP 1. We did=20 >a limited=20 >> demonstration of that (with HIP) over two years ago, in a real but=20 >> specific (3GPP) environment. So, I have some foundation for my=20 >> belief, even though I have to admit that AFAIK nobody has worked out=20 >> the details for the fully generic case. >>=20 >> > I'm sure you didn't miss this but it should be emphasized.=20 >> I think it >> > will take far less time to widely deploy LISP then it would either >> > SHIM6 or HIP. >>=20 >> If we were to implement SHIM6 or HIP in the hosts, I would agree. =20 >> But with proxied SHIM6 or HIP, I don't see any necessary differences. >>=20 >> > Just less things to touch as well as LISP being a much simpler=20 >> > solution. >>=20 >> I don't believe that LISP would end up simpler, at least=20 >compared to =20 >> SHIM6, in the end of the day when all details have been=20 >worked out. =20 >> As you know, each new proposal is initially simpler than the=20 >existing=20 >> ones, and grows more complex (than it initially is) as the=20 >details are=20 >> fleshed out. >>=20 >> If we measure the complexity in terms of LoC (in the C programming=20 >> language), I believe that all these three proposals add the order of=20 >> 10000 LoC into realistic implementations. We have reported those=20 >> numbers for HIP for a number of years now; I haven't seen numbers for >> SHIM6 but I believe they are pretty similar; maybe slightly smaller=20 >> than for HIP, but not much. LISP might get along with slightly less=20 >> (e.g. 3000-4000 LoC once the security is >> there) due to employing existing tunnelling, but I wouldn't=20 >expect any=20 >> orders of magnitude smaller complexity. But again, I may be=20 >> completely wrong here; I'm very interested in seeing your=20 >numbers once=20 >> you've got the prototype ready. >>=20 >> So, to me, the current "simplicity" of LISP (compared to SHIM6 and >> HIP) is a result of two factors: First, it is still at the=20 >idea level,=20 >> without sufficient details. Second, it is using constructions that=20 >> are familiar to the operator community (such as tunnelling and >> ICMP) while the other proposals use more specialised (and more >> optimised!) constructions. As I argued above, I don't believe there=20 >> will be any significant complexity differences in terms of=20 >> implementation or specification complexity, once all the=20 >details will=20 >> be there. And, as I argue separately (both above and=20 >below), I don't=20 >> believe there will be any significant differences in the terms of=20 >> deployment complexity, either. >>=20 >>=20 >> > upon. In many cases I fully agree with you, e.g., what comes=20 >> to the importance of deployment.> >>=20 >> >> However, as I tied to outline in draft-nikander-ram-generix-=20 >> >> proxying-00.txt, also host-based approaches allow such=20 >> placement by=20 >> >> "stretching" the stack into a wire. In the case of the >> > >> > Yes, any proposal can be tweaked to look like other ones.=20 >> The gem in=20 >> > the rough is what the original intention was for the design (and=20 >> > actually sticking to it). >>=20 >> I think I have to strongly disagree here. I don't believe=20 >> the question is about tweaking. I believe that the question=20 >> is about the implementation ("horizontal") dimension rather=20 >> than the architectural >> ("vertical") dimension. To me, the real differences lie in=20 >> security constructions, and there in the underlying trust=20 >> model, and in the identifiers. In LISP, the identifier=20 >> differences lead to your very nice LISP 1, 1.5, 2, 3 genera=20 >> construction, which I appreciate very much. It is _very_=20 >> nicely worked out. But a similar set of identifier=20 >> structures can be applied also to SHIM6 (which is at level >> 1 currently) and to HIP (which is at level 1.5 or 2 currently). >>=20 >> >> EIDs being routable (as for LISP 1 or 1.5), there is also=20 >> >> considerable freedom in placing the proxies in the network; see=20 >> >> Section 7 of the draft. >> > >> > Yep, because you don't want to change the numerous intra-domain=20 >> > routers. LISP is also trying to optimize on the number of=20 >> changes to=20 >> > routers as well. Even the amount of code in the ones that will do=20 >> > LISP. >>=20 >> I don't see any real difference here between LISP and SHIM6=20 >> (and maybe HIP), since the same identifier genera (1, 1.5, 2,=20 >> 3) can also be applied in all two (or three) cases. >>=20 >> >> If tunnelling (with all its known drawbacks) is=20 >considered to be a=20 >> >> better encapsulation method that what is currently defined for >> >> SHIM6 or HIP, it would be a no-brainer to adjust SHIM6 and/or HIP=20 >> >> accordingly. >> > >> > Hmm, I don't see this. And you said it, the devil is in the=20 >> details.=20 >> > So I have no idea what you mean by adjusting SHIM6/HIP=20 >accordingly.=20 >> > You mean accordingly to LISP? >>=20 >> Sorry for being obscure. What I meant is that if we think=20 >> that tunnelling is a better method for encapsulation than the=20 >> SHIM6 context tag or the encapsulation flexibility in HIP,=20 >> both SHIM6 and HIP could be easily adjusted to use tunnelling. >>=20 >>=20 >> > [W.r.t LISP security design] I get comments like: >>=20 >> Let me try those for SHIM6/HIP: >>=20 >> > "if you put security in LISP, do it without a PKI" >>=20 >> Check for both SHIM6 and HIP. >>=20 >> > "try to do it with no state and no 3-way handshake" >>=20 >> I believe that is pretty impossible, or alternatively would=20 >> increase the packet size to an unbearable level. For an old=20 >> paper on the topic (not addressing it directly but laying=20 >> some theoretical =20 >> foundation), consider our 1997 paper on "stateless connections". =20 >> (Sorry, I'm offline while writing this but it can be found on=20 >> my publications page.) >>=20 >> > "don't depend on a third-party" >>=20 >> Check for both SHIM6 and HIP. >>=20 >> > "we really don't need it at all" >>=20 >> Now, that is an interesting argument. It may be true,=20 >> depending on your trust model. Certainly, a single ISP or a=20 >> mutually fully trusting ISP coalition could deploy a=20 >> LISP-like structure without any security. But then, what=20 >> would be the functional difference from using properly=20 >> configured, dynamic MPLS tunnels? >>=20 >> > "worry about it later, give me bits to play with first" >>=20 >> That is the attitude that, IMHO, has brought us with the=20 >> current DDoS problems. >>=20 >>=20 >> > I believe LISP with security can get deployed sooner than=20 >if SHIM6/=20 >> > HIP did not have security. Just less things to touch. >>=20 >> I think this is the crux of our disagreement. I appreciate=20 >> your opinion, but I don't believe it to be _necessarily_=20 >> true. But then, someone needs to figure out exactly how to=20 >> proxy SHIM6 or HIP in the generic case. There may be details=20 >> there that I cannot foresee and make such proxying approach=20 >> much more complex than I currently think. But then, as I=20 >> said, I believe adding security to LISP makes it clearly more=20 >> complex than it currently looks like. >>=20 >> The other part of the argument would be the other potential=20 >> architectural benefits from the different approaches. That=20 >> we haven't touched yet. But I think it also warrants=20 >> distinct messages instead of burying it here. >>=20 >> --Pekka Nikander >>=20 >>=20 >> _______________________________________________ >> RAM mailing list >> RAM@iab.org >> https://www1.ietf.org/mailman/listinfo/ram >>=20 > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 20 04:01:03 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQpH-0008Ss-AP; Tue, 20 Feb 2007 03:58:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJQpG-0008Sn-R7 for ram@iab.org; Tue, 20 Feb 2007 03:58:18 -0500 Received: from smtp-1.smtp.ucla.edu ([169.232.46.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJQpF-0007pz-FE for ram@iab.org; Tue, 20 Feb 2007 03:58:18 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.145]) by smtp-1.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l1K8wGYX024622 for ; Tue, 20 Feb 2007 00:58:16 -0800 Received: from [192.168.8.100] (pool-71-105-96-215.lsanca.dsl-w.verizon.net [71.105.96.215]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l1K8wFlE018873 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 20 Feb 2007 00:58:16 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 20 Feb 2007 00:58:58 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.136 X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > What bothers me about the LISP 1 proposal is that the IDs need be > routable in the RLOC topology for it to work. It still requires > renumbering when changing access providers. From this pespective the > LISP2 seems more attractive. > > 2 variants of it are offered in the LISP2 presentation. It seems to me > that combined use of the two variants would offer the good properties: > default router should intercept DNS requests (which I do not believe > will add additional latency) AND do lookup for destination EIDs that > were used without a DNS query to begin with (with additional > latency and > dropping of first packets). > > In scaling the LISP it seems essential that the EIDs are also from an > aggregateable space, so that same set of RLOCs could be shared for big > number of EIDs without requiring EID specific entries in the caches. I agree with the above points, LISP2 also seems to be the more promising in terms of scalability of routing table. Current draft assumes EIDs inside a network are injected into the tunnel routers (ITR/ETR), which may not scale if EIDs are not aggregateable. An alternative approach is to also push this information to DNS. For instance, the information in DNS can also include (besides the ETR's RLOC), the last hop router EID (let's call it destRouterID) where the dest host is connected to. Once the packet reaches the dest network, it's re-encapsulated by the ETR with a dest addr=destRouterID, and once it reaches the destRouterID using IGP, the outer header is stripped off and the packet is finally delivered to the dest host. This approach might reduce the number of ETRs in each network as well as the number of entries in the global routing table. --Ricardo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 20 10:53:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXG5-0006ou-PY; Tue, 20 Feb 2007 10:50:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJXG4-0006om-9R for ram@iab.org; Tue, 20 Feb 2007 10:50:24 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJXG2-0000v4-UW for ram@iab.org; Tue, 20 Feb 2007 10:50:24 -0500 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by sj-iport-6.cisco.com with ESMTP; 20 Feb 2007 07:50:22 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="scan'208"; a="114490417:sNHT42605829" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1KFoLPa023333; Tue, 20 Feb 2007 10:50:21 -0500 Received: from [12.154.71.139] (rtp-vpn3-493.cisco.com [10.82.217.239]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1KFoFOA002311; Tue, 20 Feb 2007 10:50:16 -0500 (EST) Message-ID: <45DB18B6.2090505@cisco.com> Date: Tue, 20 Feb 2007 10:50:14 -0500 From: Russ White User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> In-Reply-To: <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> X-Enigmail-Version: 0.94.1.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1564; t=1171986621; x=1172850621; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=riw@cisco.com; z=From:=20Russ=20White=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20 |To:=20=22Ricardo=20V.=20Oliveira=22=20; bh=SDA5lI0x+Y+7nFaz7HYfyeUJDe+LAXrAhlzhuIMTLbg=; b=UOaK45y9Sql2hHeQ0DoUhxnbu0UUNIBZ2KoZBqwswOWS4kKabTfctSpR6ZQHmUBY1zUL/Rs/ +JtXw5n3M04dnOpv4qvaMdvKuJ6Seugyu1VIo8iDl3OXzgYxBgixKRLP; Authentication-Results: rtp-dkim-1; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > For instance, the information in DNS can also include (besides the ETR's > RLOC), the last hop router EID (let's call it destRouterID) where the > dest host is connected to. > Once the packet reaches the dest network, it's re-encapsulated by the > ETR with a dest addr=destRouterID, and once it reaches the destRouterID > using IGP, the outer header is stripped off and the packet is finally > delivered to the dest host. > This approach might reduce the number of ETRs in each network as well as > the number of entries in the global routing table. Doesn't this just push the state change problem from the distributed routing database into the distributed naming database? In reality, at some point we're probably going to face this--the relationship between names and locations must be handled in real time. Today, the solutions we have for this relate to state in NATs, and state on the end host. The question may come down to--should this state be moved into the routing system? If so, how should it be moved? There are a number of other problems that swirl around this, such as security, etc, etc.... And, finally--what's the economic and social model for this move, if the move is determined to be the best option to "solve the problem?" :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFF2xi2ER27sUhU9OQRAl40AJ4gYRHirzkZzEti8VevKdedJcwepQCeO543 ew3A0RAnieQ/B9J70JTzMVM= =1TMX -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 20 17:45:22 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdhO-0002ws-UJ; Tue, 20 Feb 2007 17:43:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJdhN-0002ua-Nh for ram@iab.org; Tue, 20 Feb 2007 17:43:01 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJdhM-0002m2-Dx for ram@iab.org; Tue, 20 Feb 2007 17:43:01 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 20 Feb 2007 14:42:59 -0800 X-IronPort-AV: i="4.14,197,1170662400"; d="scan'208"; a="391392591:sNHT132581968" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1KMgxBb015951; Tue, 20 Feb 2007 14:42:59 -0800 Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.142.83]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1KMgtnF028155; Tue, 20 Feb 2007 14:42:55 -0800 (PST) Received: from vaf-lnx1.cisco.com (localhost.localdomain [127.0.0.1]) by vaf-lnx1.cisco.com (8.13.1/8.13.1) with ESMTP id l1KMgrVs015293; Tue, 20 Feb 2007 14:42:53 -0800 Received: (from vaf@localhost) by vaf-lnx1.cisco.com (8.13.1/8.13.1/Submit) id l1KMgdwE015289; Tue, 20 Feb 2007 14:42:39 -0800 X-Authentication-Warning: vaf-lnx1.cisco.com: vaf set sender to vaf@cisco.com using -f Date: Tue, 20 Feb 2007 14:42:39 -0800 From: Vince Fuller To: jarno.rajahalme@nokia.com Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Message-ID: <20070220224239.GB15102@vaf-lnx1.cisco.com> References: <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=747; t=1172011379; x=1172875379; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=KUdtA9vB2+AQ1MhoUafP2Wa3spXzeN7EAEwMr1QFwgs=; b=PIsNpBlE1/dIm+48nyF4K/5hNBndHp74y6maXlkHoMczFhXVUv4kiKzDpljxIM2IB7GDTk6E DInJjRCLApFgmg7uPiyQNqZX4vgWIs6d3DIrH9Ot1DLoyoC7gCCOIUQ+; Authentication-Results: sj-dkim-5; header.From=vaf@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: pekka.nikander@nomadiclab.com, ram@iab.org, Jim.Bound@hp.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Also an interesting variant of the LISP (1.5?) would be to have the EID > be routable, but not necessarily to the destination network, but to a > kind of "EID/RLOC home agent" that could tunnel the packets to the > destination network (that would then do the ICMP setup with the source > network just like in LISP1). So instead of having separate routes to > each and every destination network on the EID space, the network would > have radically fewer number of routes in the EID space to "EID/RLOC home > agent providers" (compare to Mobile IP virtual home networks), where the > destination networks' edge routers would register their RLOCs. This is a good summary of the salient difference between LISP1 and LISP1.5. --Vince _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 21 00:02:43 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJjbT-0006Vt-9S; Wed, 21 Feb 2007 00:01:19 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJjbS-0006Ui-6Y for ram@iab.org; Wed, 21 Feb 2007 00:01:18 -0500 Received: from smtp-3.smtp.ucla.edu ([169.232.48.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJjbQ-0006Gd-Pv for ram@iab.org; Wed, 21 Feb 2007 00:01:18 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-3.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l1L51DEK021312 for ; Tue, 20 Feb 2007 21:01:13 -0800 Received: from [192.168.8.100] (pool-71-105-96-215.lsanca.dsl-w.verizon.net [71.105.96.215]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l1L51Cc1002755 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 20 Feb 2007 21:01:13 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <45DB18B6.2090505@cisco.com> References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> <45DB18B6.2090505@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <315D20C5-8441-4798-A6A7-F47F974B9BD4@CS.UCLA.EDU> Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 20 Feb 2007 21:02:03 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.136 X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Feb 20, 2007, at 7:50 AM, Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > >> For instance, the information in DNS can also include (besides the >> ETR's >> RLOC), the last hop router EID (let's call it destRouterID) where the >> dest host is connected to. >> Once the packet reaches the dest network, it's re-encapsulated by the >> ETR with a dest addr=destRouterID, and once it reaches the >> destRouterID >> using IGP, the outer header is stripped off and the packet is finally >> delivered to the dest host. >> This approach might reduce the number of ETRs in each network as >> well as >> the number of entries in the global routing table. > > Doesn't this just push the state change problem from the distributed > routing database into the distributed naming database? The scheme is the same as LISPv2, it just appends to RLOC the EID of the router where the dest host is currently connected to, avoiding of doing routing by dest host EID at destination network. As I understand, EIDs are not topological aggregatable, i.e., my laptop can have an EID, which is kept as I move from network to network. --Ricardo > In reality, at > some point we're probably going to face this--the relationship between > names and locations must be handled in real time. Today, the solutions > we have for this relate to state in NATs, and state on the end > host. The > question may come down to--should this state be moved into the routing > system? If so, how should it be moved? There are a number of other > problems that swirl around this, such as security, etc, etc.... > > And, finally--what's the economic and social model for this move, > if the > move is determined to be the best option to "solve the problem?" > > :-) > > Russ > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.3 (Darwin) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iD8DBQFF2xi2ER27sUhU9OQRAl40AJ4gYRHirzkZzEti8VevKdedJcwepQCeO543 > ew3A0RAnieQ/B9J70JTzMVM= > =1TMX > -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 21 01:30:04 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJkxw-000519-Nu; Wed, 21 Feb 2007 01:28:36 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJkxv-000513-Fq for ram@iab.org; Wed, 21 Feb 2007 01:28:35 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJkxt-0006PK-Rj for ram@iab.org; Wed, 21 Feb 2007 01:28:35 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 20 Feb 2007 22:28:33 -0800 X-IronPort-AV: i="4.14,198,1170662400"; d="scan'208"; a="361949965:sNHT52783758" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1L6SXaQ032001; Tue, 20 Feb 2007 22:28:33 -0800 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1L6SKnX009209; Tue, 20 Feb 2007 22:28:32 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:28:31 -0800 Received: from [192.168.1.180] ([10.21.148.119]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:28:31 -0800 In-Reply-To: References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 20 Feb 2007 22:28:31 -0800 To: "" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Feb 2007 06:28:31.0250 (UTC) FILETIME=[8157B720:01C75581] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4779; t=1172039313; x=1172903313; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=akfZQIbODnD/5mhDnIPW0sXI6nvTCt+zEQV/XfxYEGo=; b=aUa6U0G57vXWblEG08pviM/IjX8ulkvYvkW2fjDqSThTF+B4sD2MkeQEqun5dnkbKLVGjeQn LbsFWd5Gf4jpdFeVzqYLZWbAbq2t1T9pHJdyvFHEuARcT/nGe2F6/VfE; Authentication-Results: sj-dkim-7; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b132cb3ed2d4be2017585bf6859e1ede Cc: pekka.nikander@nomadiclab.com, ram@iab.org, Jim.Bound@hp.com X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > What bothers me about the LISP 1 proposal is that the IDs need be > routable in the RLOC topology for it to work. It still requires > renumbering when changing access providers. From this pespective the > LISP2 seems more attractive. Let me try to clear up some things: o Routable IDs means the IP address, used as an ID can be used to do a lookup in a FIB to forward a packet. That does not mean it has to be aligned with the topology that PA addressing is representing. If a site uses PA addresses as EIDs, this isn't much of a problem. The site can help the core scale by injecting less routes but doesn't have renumbering benefits because if it cancels it's contract with the ISP that assigned the PA block used for EIDs, it would have to renumber. However, LISP doesn't introduce this disadvantage. If a site uses PI addresses as EIDs, renumbering can always be avoided. But starting off PI addresses will be routable because if they are being allocated today, they are routable. We certainly want to get away from this and hence using ICMP and not relying on a third-party database infrastructure is also achievable, LISP 1.5, allows to route EIDs over a separate, non- congruent, very aggregatable topology which doesn't have the frequency of changes that a physical connection to an ISP would. You have to make tradeoffs, and to get the fast deployment and touch as few things as possible, LISP 1.5 is quite desirable. o If the entire world goes to PI addresses as EIDs, then we have no choice to use a third-party and LISP 2 ala DNS or LISP 3 ala DHTs are the only choices. But please be patient and look at the reason we numbered the variants 1, 1.5, 2, and 3. It is in the order of deployment stages. With LISP 1, we have to get experience with the encapsulation (should be no surprises here), ITR and ETR placement, how TE will be used, as well as locator reachability detection and selection. That is a lot for a first phase. Once the basic correctness is done, then we can transition to forwarding packets on a separate topology using LISP 1.5. There is work here because one needs to decide to either do: o A configured tunnel topology with static EID-prefix routes. o A configured tunnel topology advertising EID-prefix routes in BGP. o Use the same Internet topology but a different VRF inside of BGP that has inter-domain reach. o Use a different AF/SAFI in BGP for this. And for LISP 2 and using DNS, since we really want the EID-to-RLOC mapping before the host sends any useful packets, we need to snoop on the DNS reply. That will probably sit uneasy in some people's minds. So I was hoping that LISP 3 using DHTs would be a better model. > 2 variants of it are offered in the LISP2 presentation. It seems to me 4 variants. > that combined use of the two variants would offer the good properties: > default router should intercept DNS requests (which I do not believe > will add additional latency) AND do lookup for destination EIDs that > were used without a DNS query to begin with (with additional > latency and > dropping of first packets). The thought was to intercept DNS replies which had the EID-to-RLOC mapping in the Addtional Info field of the reply. This would be present because of the new RR associated with the entry, which the hosts would ignore, but the ITR would use. Comments? > In scaling the LISP it seems essential that the EIDs are also from an > aggregateable space, so that same set of RLOCs could be shared for big > number of EIDs without requiring EID specific entries in the caches. Absolutely. That is planned and spec'ed in the -00 version. > Also an interesting variant of the LISP (1.5?) would be to have the > EID > be routable, but not necessarily to the destination network, but to a > kind of "EID/RLOC home agent" that could tunnel the packets to the > destination network (that would then do the ICMP setup with the source > network just like in LISP1). Sure, but is this a community place? Not sure if how many sites would use the same box to do this. I think sites would want to put the configuration in their own boxes and not rely on a central place. But the tunnel topology to route these initial packets could be homed at each CE router. > So instead of having separate routes to > each and every destination network on the EID space, the network would > have radically fewer number of routes in the EID space to "EID/RLOC > home > agent providers" (compare to Mobile IP virtual home networks), > where the That was our intention of LISP 1.5. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 21 01:31:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl0H-0006pn-Fk; Wed, 21 Feb 2007 01:31:01 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl0C-0006oU-Sj for ram@iab.org; Wed, 21 Feb 2007 01:30:58 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJl0B-0006vb-JF for ram@iab.org; Wed, 21 Feb 2007 01:30:56 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 20 Feb 2007 22:30:55 -0800 X-IronPort-AV: i="4.14,198,1170662400"; d="scan'208"; a="114706368:sNHT45181359" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1L6Ust5021694; Tue, 20 Feb 2007 22:30:54 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1L6UoDo006195; Tue, 20 Feb 2007 22:30:54 -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, 20 Feb 2007 22:30:54 -0800 Received: from [192.168.1.180] ([10.21.148.119]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:30:54 -0800 In-Reply-To: <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 20 Feb 2007 22:30:54 -0800 To: "Ricardo V. Oliveira" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Feb 2007 06:30:54.0100 (UTC) FILETIME=[D67CE540:01C75581] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1125; t=1172039455; x=1172903455; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=MzPH2TMJimRtUJIJx/J1fCk8s6zvTfEq9zbQ9YOUC2M=; b=EQMkzGjgjKPskP/PLhQAWggylh6Q3e00pbHrJYHgFJllGoD7A3Ycn1w7SpDdtw2s4X3bGNOD Nm9IIVOuXn2GSyYSV7SznnD57zP/4AIvm0foxRA1DCngjLJVR4n5l9/r; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Current draft assumes EIDs inside a network are injected into the > tunnel routers (ITR/ETR), which may not scale if EIDs are not > aggregateable. Not for LISP 2 and 3. > An alternative approach is to also push this information to DNS. > For instance, the information in DNS can also include (besides the > ETR's RLOC), the last hop router EID (let's call it destRouterID) > where the dest host is connected to. That is the RLOC for the EID. This is LISP 2 when using DNS or LISP 3 when using, say DHTs. > Once the packet reaches the dest network, it's re-encapsulated by > the ETR with a You have to be more clear about "dest network". Do you mean destination site or last-hop subnet at the destination site? > dest addr=destRouterID, and once it reaches the destRouterID using > IGP, the outer header is stripped off and the packet is finally > delivered to the dest host. > This approach might reduce the number of ETRs in each network as > well as the number of entries in the global routing table. Agree, but don't understand your re-encapsulated comment. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 21 01:31:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl0L-0006yo-Tm; Wed, 21 Feb 2007 01:31:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJl0K-0006w0-SQ for ram@iab.org; Wed, 21 Feb 2007 01:31:04 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HJl0J-0006vq-J3 for ram@iab.org; Wed, 21 Feb 2007 01:31:04 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 20 Feb 2007 22:31:03 -0800 X-IronPort-AV: i="4.14,198,1170662400"; d="scan'208"; a="763682811:sNHT44044184" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l1L6V3kW011367; Tue, 20 Feb 2007 22:31:03 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1L6V2Dk006318; Tue, 20 Feb 2007 22:31:02 -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, 20 Feb 2007 22:31:02 -0800 Received: from [192.168.1.180] ([10.21.148.119]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Feb 2007 22:31:01 -0800 In-Reply-To: <20070220224239.GB15102@vaf-lnx1.cisco.com> References: <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> <20070220224239.GB15102@vaf-lnx1.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <505BCBF6-28F0-4939-996E-ADA8329781A4@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 20 Feb 2007 22:31:02 -0800 To: Vince Fuller X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Feb 2007 06:31:01.0913 (UTC) FILETIME=[DB251090:01C75581] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=849; t=1172039463; x=1172903463; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=bKt1fXjXLlBldwAZWwtoYXssTg+bD/oI06d7rY9rLks=; b=HGB8BFFDbU+GdBGAwGngWDdTFLI05WFvAGSuzoQTX2Oj1OkrsPH3Zpmv3yT51+GhUNrJtfjk Y1jHOqm/I8x2wD6C7+Oj6hEiQxIjgX5fl2jh5OTk6Xvy9feNAn1X6V4M; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Cc: pekka.nikander@nomadiclab.com, Jim.Bound@hp.com, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Also an interesting variant of the LISP (1.5?) would be to have >> the EID >> be routable, but not necessarily to the destination network, but to a >> kind of "EID/RLOC home agent" that could tunnel the packets to the >> destination network (that would then do the ICMP setup with the >> source >> network just like in LISP1). So instead of having separate routes to >> each and every destination network on the EID space, the network >> would >> have radically fewer number of routes in the EID space to "EID/ >> RLOC home >> agent providers" (compare to Mobile IP virtual home networks), >> where the >> destination networks' edge routers would register their RLOCs. > > This is a good summary of the salient difference between LISP1 and > LISP1.5. And we will add it to the next rev of the spec. Thanks! Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 21 13:39:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwLI-0000Y6-NG; Wed, 21 Feb 2007 13:37:28 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HJwLH-0000Xy-38 for ram@iab.org; Wed, 21 Feb 2007 13:37:27 -0500 Received: from smtp-6.smtp.ucla.edu ([169.232.48.137]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HJwLF-0005Pq-LA for ram@iab.org; Wed, 21 Feb 2007 13:37:27 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-6.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l1LIbKDf023098 for ; Wed, 21 Feb 2007 10:37:20 -0800 Received: from [131.179.96.243] (Cs-96-243.CS.UCLA.EDU [131.179.96.243]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l1LIbK7k029829 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Feb 2007 10:37:20 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97AC3CC6-B73A-4D1C-B850-9B808C42D76C@CS.UCLA.EDU> Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Wed, 21 Feb 2007 10:38:11 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.48.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Current draft assumes EIDs inside a network are injected into the >> tunnel routers (ITR/ETR), which may not scale if EIDs are not >> aggregateable. > > Not for LISP 2 and 3. Is there any LISPv2/3 specification besides the draft? So if EIDs are not injected in border routers at destination network, how do these routers route the packets to the dest host? > >> An alternative approach is to also push this information to DNS. >> For instance, the information in DNS can also include (besides the >> ETR's RLOC), the last hop router EID (let's call it destRouterID) >> where the dest host is connected to. > > That is the RLOC for the EID. This is LISP 2 when using DNS or LISP > 3 when using, say DHTs. > >> Once the packet reaches the dest network, it's re-encapsulated by >> the ETR with a > > You have to be more clear about "dest network". Do you mean > destination site or last-hop subnet at the destination site? I meant border router at destination network (BGP speaker). > >> dest addr=destRouterID, and once it reaches the destRouterID using >> IGP, the outer header is stripped off and the packet is finally >> delivered to the dest host. >> This approach might reduce the number of ETRs in each network as >> well as the number of entries in the global routing table. > > Agree, but don't understand your re-encapsulated comment. What I meant is that the packet will be encapsulated twice. It's encapsulated by the ITR once it leaves the source network. It's decapsulated by the ETR border router once it gets to the destination network. This same ETR encapsulates again the packet to the desRouterID, where the dest host EID is connected to. --Ricardo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 22 01:17:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK7G3-0005wI-Ca; Thu, 22 Feb 2007 01:16:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK7G2-0005pB-2q for ram@iab.org; Thu, 22 Feb 2007 01:16:46 -0500 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HK7G0-0002dj-GX for ram@iab.org; Thu, 22 Feb 2007 01:16:46 -0500 Received: from ind-dkim-2.cisco.com ([64.104.140.59]) by ind-iport-1.cisco.com with ESMTP; 23 Feb 2007 00:35:50 +0530 X-IronPort-AV: i="4.14,204,1170613800"; d="scan'208"; a="75703108:sNHT80111756" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ind-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1M6GU2E003821; Thu, 22 Feb 2007 11:46:31 +0530 Received: from xbh-hkg-411.apac.cisco.com (xbh-hkg-411.cisco.com [64.104.123.72]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1M6GJU7010939; Thu, 22 Feb 2007 14:16:25 +0800 (CST) Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 14:16:22 +0800 Received: from [192.168.1.180] ([10.70.230.84]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 14:16:21 +0800 In-Reply-To: <97AC3CC6-B73A-4D1C-B850-9B808C42D76C@CS.UCLA.EDU> References: <974B9EF3-F16C-430C-B3F2-5212FA0EBF29@nomadiclab.com><19004347-2E10-4DE2-92C3-D48ED9672E09@nomadiclab.com> <816DD9299957E547B5D758D7F977D6DC0163A306@tayexc14.americas.cpqcorp.net> <2E6F42F0-CA8A-4269-B93F-8A5E83236C86@cs.ucla.edu> <97AC3CC6-B73A-4D1C-B850-9B808C42D76C@CS.UCLA.EDU> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Wed, 21 Feb 2007 22:08:40 -0800 To: "Ricardo V. Oliveira" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Feb 2007 06:16:21.0856 (UTC) FILETIME=[F900C600:01C75648] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1969; t=1172124991; x=1172988991; c=relaxed/simple; s=inddkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=g6kM9BoUDajxBmzHrokNvYklpSe719mi9XC3gbR83cg=; b=SZFAF1pImmDLfyL6flR0QO0edoQ+PlFvXEOpYUoLOzb8EkQdvga7zt3t+t0dvy3jq77zJCK2 iJLS8OBlv/IIVNcQjq5OvE1D0pIPUPAkwS0RWfKpTrxsjlpkyKydFnjo; Authentication-Results: ind-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/inddkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Is there any LISPv2/3 specification besides the draft? Not yet. > So if EIDs are not injected in border routers at destination > network, how do these routers route the packets to the dest host? In LISP 1 they are injected. In LISP 1.5, they are injected into a routing protocol that runs on an alternate non-congruent to the locator topology. >>> An alternative approach is to also push this information to DNS. >>> For instance, the information in DNS can also include (besides >>> the ETR's RLOC), the last hop router EID (let's call it >>> destRouterID) where the dest host is connected to. >> >> That is the RLOC for the EID. This is LISP 2 when using DNS or >> LISP 3 when using, say DHTs. >> >>> Once the packet reaches the dest network, it's re-encapsulated by >>> the ETR with a >> >> You have to be more clear about "dest network". Do you mean >> destination site or last-hop subnet at the destination site? > I meant border router at destination network (BGP speaker). When it is pushed into DNS, the last-hop router's IP address is represented as the locator for the EIDs assign to the hosts it is decapsulating for. >>> dest addr=destRouterID, and once it reaches the destRouterID >>> using IGP, the outer header is stripped off and the packet is >>> finally delivered to the dest host. >>> This approach might reduce the number of ETRs in each network as >>> well as the number of entries in the global routing table. >> >> Agree, but don't understand your re-encapsulated comment. > What I meant is that the packet will be encapsulated twice. It's > encapsulated by the ITR once it leaves the source network. It's > decapsulated by the ETR border router once it gets to the > destination network. This same ETR encapsulates again the packet to > the desRouterID, where the dest host EID is connected to. You don't need to do this. Don't see the value at all. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 22 02:46:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8ck-0002B1-LV; Thu, 22 Feb 2007 02:44:18 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HK8cj-0002AV-Fs for ram@iab.org; Thu, 22 Feb 2007 02:44:17 -0500 Received: from smtp-7.smtp.ucla.edu ([169.232.46.138]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HK8ci-0005Ov-0a for ram@iab.org; Thu, 22 Feb 2007 02:44:17 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-7.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l1M7iCkp010927 for ; Wed, 21 Feb 2007 23:44:12 -0800 Received: from [192.168.8.100] (pool-71-105-96-215.lsanca.dsl-w.verizon.net [71.105.96.215]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l1M7hMIP031891 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Wed, 21 Feb 2007 23:44:12 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@iab.org From: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Wed, 21 Feb 2007 23:45:05 -0800 X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > In LISP 1 they are injected. In LISP 1.5, they are injected into a > routing protocol that runs on an alternate non-congruent to the > locator topology. > So I take that in LISPv2 EIDS are not injected anywhere, but are rather looked up in DNS. A question:what if my laptop is behind a firewall connected to a router without public interfaces? What is my RLOC in this case? It seems currently LISP assumes the dest host is always directly connected to the ETR, which is probably too restrictive. Also, the smaller the number of ETRs, the shorter the routing table is. If we want to be able to accommodate non-ETR last-hop routers (but inside the same network as the ETRs), you need to include besides the RLOC, the destRouterID of the last hop routers, and re-encapsulate the packets at ETRs. --Ricardo > > >>>> An alternative approach is to also push this information to DNS. >>>> For instance, the information in DNS can also include (besides >>>> the ETR's RLOC), the last hop router EID (let's call it >>>> destRouterID) where the dest host is connected to. >>>> >>> >>> That is the RLOC for the EID. This is LISP 2 when using DNS or >>> LISP 3 when using, say DHTs. >>> >>> >>>> Once the packet reaches the dest network, it's re-encapsulated >>>> by the ETR with a >>>> >>> >>> You have to be more clear about "dest network". Do you mean >>> destination site or last-hop subnet at the destination site? >>> >> I meant border router at destination network (BGP speaker). >> > > When it is pushed into DNS, the last-hop router's IP address is > represented as the locator for the EIDs assign to the hosts it is > decapsulating for. > > >>>> dest addr=destRouterID, and once it reaches the destRouterID >>>> using IGP, the outer header is stripped off and the packet is >>>> finally delivered to the dest host. >>>> This approach might reduce the number of ETRs in each network as >>>> well as the number of entries in the global routing table. >>>> >>> >>> Agree, but don't understand your re-encapsulated comment. >>> >> What I meant is that the packet will be encapsulated twice. It's >> encapsulated by the ITR once it leaves the source network. It's >> decapsulated by the ETR border router once it gets to the >> destination network. This same ETR encapsulates again the packet >> to the desRouterID, where the dest host EID is connected to. >> > > You don't need to do this. Don't see the value at all. > > Dino > > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 22 12:25:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHfS-00026T-AJ; Thu, 22 Feb 2007 12:23:42 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKHfR-00026H-4y for ram@iab.org; Thu, 22 Feb 2007 12:23:41 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKHfO-0003iD-R6 for ram@iab.org; Thu, 22 Feb 2007 12:23:41 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 22 Feb 2007 09:23:33 -0800 X-IronPort-AV: i="4.14,207,1170662400"; d="scan'208"; a="362396333:sNHT12310573984" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l1MHNXwr015566; Thu, 22 Feb 2007 09:23:33 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1MHNVDs010014; Thu, 22 Feb 2007 09:23:31 -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); Thu, 22 Feb 2007 09:23:22 -0800 Received: from [12.154.71.85] ([10.21.153.64]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 09:23:22 -0800 In-Reply-To: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Thu, 22 Feb 2007 09:23:23 -0800 To: "Ricardo V. Oliveira" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Feb 2007 17:23:22.0341 (UTC) FILETIME=[27122950:01C756A6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1450; t=1172165013; x=1173029013; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=RRgSy+m/GyAmIpbY0ig5p+eFXI7T1JEkESiuinRTHhM=; b=koW/AAetFO55wJndtd4WrFUgZTDUFdDDzalmTpUKDt+nXnEiWkrPgkiEMxliUsAsSH1k7mQ3 oPfLEMha5FN6Dk9x0BmtnXi7Eo1uy2Cb9skiFRfAYc3pubcKw5nAnw6M; Authentication-Results: sj-dkim-3; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> In LISP 1 they are injected. In LISP 1.5, they are injected into a >> routing protocol that runs on an alternate non-congruent to the >> locator topology. >> > So I take that in LISPv2 EIDS are not injected anywhere, but are > rather looked up in DNS. Right. > A question:what if my laptop is behind a firewall connected to a > router without public interfaces? What is my RLOC in this case? The firewall (assuming it's a NAT) will translate the destination address inserted by the host to a global address. This global address, at this point of the data path, is an EID. When there is a ITR downstream (or the NAT itself is an ITR), a new IP header is prepended which contain the Locator addresses. > It seems currently LISP assumes the dest host is always directly > connected to the ETR, which is probably too restrictive. Also, the > smaller the number of ETRs, the shorter the routing table is. No, it does not assume that. The example provided indicated this. But if you want your mapping cache to be centralized, the ETR can be a your pair of edge CE routers. > If we want to be able to accommodate non-ETR last-hop routers (but > inside the same network as the ETRs), you need to include besides > the RLOC, the destRouterID of the last hop routers, and re- > encapsulate the packets at ETRs. In this case, the EID is used to route *inside* the destination site. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 22 15:11:09 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKFb-0008W9-8E; Thu, 22 Feb 2007 15:09:11 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKFZ-0008Ve-9F for ram@iab.org; Thu, 22 Feb 2007 15:09:09 -0500 Received: from smtp-4.smtp.ucla.edu ([169.232.46.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKKFW-00051N-Un for ram@iab.org; Thu, 22 Feb 2007 15:09:08 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.48.151]) by smtp-4.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l1MK946A016441 for ; Thu, 22 Feb 2007 12:09:04 -0800 Received: from [131.179.96.243] (Cs-96-243.CS.UCLA.EDU [131.179.96.243]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l1MK93lS021367 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Feb 2007 12:09:04 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Thu, 22 Feb 2007 12:09:57 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.46.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Feb 22, 2007, at 9:23 AM, Dino Farinacci wrote: >>> In LISP 1 they are injected. In LISP 1.5, they are injected into >>> a routing protocol that runs on an alternate non-congruent to the >>> locator topology. >>> >> So I take that in LISPv2 EIDS are not injected anywhere, but are >> rather looked up in DNS. > > Right. > >> A question:what if my laptop is behind a firewall connected to a >> router without public interfaces? What is my RLOC in this case? > > The firewall (assuming it's a NAT) will translate the destination > address inserted by the host to a global address. This global > address, at this point of the data path, is an EID. When there is a > ITR downstream (or the NAT itself is an ITR), a new IP header is > prepended which contain the Locator addresses. > >> It seems currently LISP assumes the dest host is always directly >> connected to the ETR, which is probably too restrictive. Also, the >> smaller the number of ETRs, the shorter the routing table is. > > No, it does not assume that. The example provided indicated this. > But if you want your mapping cache to be centralized, the ETR can > be a your pair of edge CE routers. > >> If we want to be able to accommodate non-ETR last-hop routers (but >> inside the same network as the ETRs), you need to include besides >> the RLOC, the destRouterID of the last hop routers, and re- >> encapsulate the packets at ETRs. > > In this case, the EID is used to route *inside* the destination site. But if you don't inject EIDs inside the site (like LISPv2), how are you going to route by EID inside the network? The same question for the NAT case, how is the NAT box route by EID to the end host? --Ricardo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Feb 22 15:39:47 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKhz-0000vR-24; Thu, 22 Feb 2007 15:38:31 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKKhw-0000uH-SJ for ram@iab.org; Thu, 22 Feb 2007 15:38:28 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKKhj-0000Zx-S2 for ram@iab.org; Thu, 22 Feb 2007 15:38:17 -0500 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 22 Feb 2007 12:38:16 -0800 X-IronPort-AV: i="4.14,207,1170662400"; d="scan'208"; a="466460367:sNHT43797808" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l1MKcFJ1007615; Thu, 22 Feb 2007 12:38:15 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l1MKc4Do014527; Thu, 22 Feb 2007 12:38:15 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 12:38:07 -0800 Received: from [10.223.50.145] ([10.21.145.125]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Feb 2007 12:38:06 -0800 In-Reply-To: <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Thu, 22 Feb 2007 12:38:07 -0800 To: "Ricardo V. Oliveira" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 22 Feb 2007 20:38:06.0768 (UTC) FILETIME=[5B883B00:01C756C1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=674; t=1172176695; x=1173040695; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=9EY0JnVhZQcw0WuE/w8cjI4VEGypoyqUVqpWCtipNkA=; b=G+VpriQB2Z6eRTiJ8lVe19FcJ/g+Ve3eBLqq/74als/Rfq4TY8OGEcA1Ap084KPPzBAnh5fk apRu+4Zs7v8f8Pq8oWFqvKBjPWfKFEYY8QEJY1nFObQN35PdlrFKszaT; Authentication-Results: sj-dkim-2; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > But if you don't inject EIDs inside the site (like LISPv2), how are > you going to route by EID inside the network? The same question for > the NAT case, how is the NAT box route by EID to the end host? The EIDs are already inside the site. A site today which is allocated a PI block (or any block for that matter) has their routers, hosts, subnets, and routing protocols already configured with addresses in that block. Remember, this is incremental, EIDs are the host addresses you see today and inside of the site is the addressing you see today. Outside of the site, you use locators which are the addresses you have in BGP today. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 23 00:58:46 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKTQs-0001Ny-Ph; Fri, 23 Feb 2007 00:57:26 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKTQr-0001Np-Mf for ram@iab.org; Fri, 23 Feb 2007 00:57:25 -0500 Received: from smtp-8.smtp.ucla.edu ([169.232.47.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKTQq-0008IE-Ao for ram@iab.org; Fri, 23 Feb 2007 00:57:25 -0500 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-8.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l1N5vNAq013004 for ; Thu, 22 Feb 2007 21:57:23 -0800 Received: from [192.168.8.100] (pool-71-105-96-215.lsanca.dsl-w.verizon.net [71.105.96.215]) (authenticated bits=0) by mail.ucla.edu (8.13.8/8.13.8) with ESMTP id l1N5vM5b013415 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Thu, 22 Feb 2007 21:57:23 -0800 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "Ricardo V. Oliveira" Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Thu, 22 Feb 2007 21:58:16 -0800 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.47.138 X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Feb 22, 2007, at 12:38 PM, Dino Farinacci wrote: >> But if you don't inject EIDs inside the site (like LISPv2), how >> are you going to route by EID inside the network? The same >> question for the NAT case, how is the NAT box route by EID to the >> end host? > > The EIDs are already inside the site. A site today which is > allocated a PI block (or any block for that matter) has their > routers, hosts, subnets, and routing protocols already configured > with addresses in that block. > > Remember, this is incremental, EIDs are the host addresses you see > today and inside of > the site is the addressing you see today. Outside of the site, you > use locators which are the addresses you have in BGP today. So in the long term, EIDs can be any number, not necessarily aligned with the network addresses of routers in the network - they reflect the ID of the host. So if the goal is to keep session alive while moving between networks (like it's mentioned in the draft) routers inside the any destination network must be able to route to an arbritary EID. Two options: either (1) EIDs are injected in IGP or (2) IGP last-hop router address is pushed to e.g. DNS to allow routing inside the network... --Ricardo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 23 09:10:12 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKb6o-0003Dk-FK; Fri, 23 Feb 2007 09:09:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKb6n-00039q-F4 for ram@iab.org; Fri, 23 Feb 2007 09:09:13 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKb6l-0005Yc-3M for ram@iab.org; Fri, 23 Feb 2007 09:09:13 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-4.cisco.com with ESMTP; 23 Feb 2007 06:09:06 -0800 X-IronPort-AV: i="4.14,211,1170662400"; d="scan'208"; a="41917497:sNHT54609813" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1NE96OC023032; Fri, 23 Feb 2007 06:09:06 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1NE94Gk005218; Fri, 23 Feb 2007 06:09:04 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 06:09:04 -0800 Received: from [10.225.15.64] ([10.21.90.144]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 06:09:03 -0800 In-Reply-To: References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Fri, 23 Feb 2007 06:09:03 -0800 To: "Ricardo V. Oliveira" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Feb 2007 14:09:03.0774 (UTC) FILETIME=[2C6FC3E0:01C75754] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2693; t=1172239746; x=1173103746; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=znoUlxl7W4AdheAeWthfBz6wtLQGy4qFMdKcc7D/ZLI=; b=kgLWjbm65RdtYJ0wactrqw0ZsobxACVd11Iv8B8ZGZeOtSV5R7szhG/L/P6ZtBREJCIB0PdR qAHxVy5ST/erTzV4OlOpHoQx9Qr2lp2xZep6IwnQowvMZ4nF6ClPcgBxlKB4OjsRryv31K5EPs TmRjpx62PBHChZaPWEStHjgbw=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> But if you don't inject EIDs inside the site (like LISPv2), how >>> are you going to route by EID inside the network? The same >>> question for the NAT case, how is the NAT box route by EID to the >>> end host? >> >> The EIDs are already inside the site. A site today which is >> allocated a PI block (or any block for that matter) has their >> routers, hosts, subnets, and routing protocols already configured >> with addresses in that block. >> >> Remember, this is incremental, EIDs are the host addresses you see >> today and inside of >> the site is the addressing you see today. Outside of the site, you >> use locators which are the addresses you have in BGP today. > So in the long term, EIDs can be any number, not necessarily > aligned with the network addresses of routers in the network - they > reflect the ID of the host. So if Yes, that is correct. We will have two namespaces, an EID namespace and a Locator namespace. The Locator namespace are the IP addresses and routes we see in the capital-I Internet today. The EID namespace are the IP addresses that are assigned to hosts and reside in DNS, as we see it today. The split is actually happening topologically, at the site-to-ISP border. Where the inner addresses are EIDs and used within a site, and the outer addresses are locators used outside of a source or destination site. I am using the term namespaces because I think this has become the defacto term among many people I have talked with. > the goal is to keep session alive while moving between networks > (like it's mentioned in the draft) routers inside the any > destination network must be able to Yes, keeping the session alive while doing "slow moves" between sites. I would consider "fast moves" to be a hand-set roaming from one part of the topology another part. We are not saying at this point how well LISP will work in the fast-move scenarios. > route to an arbritary EID. Two options: either (1) EIDs are > injected in IGP or (2) IGP last-hop router address is pushed to > e.g. DNS to allow routing inside the network... Routers route to an arbitrary EID because they know about subnet the EID is part of. EIDs are not per say injected. That is the host addresses themselves are not injected. These EID host addresses are part of a subnet and are ARP for like things work today. We really are not and don't want to change too many things. > --Ricardo Thanks for the discussion Ricardo. It allows me to be crystal clear about what our intentions are. I hope people find this valuable and not noise on the list. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 23 11:53:02 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKddA-0000B1-PN; Fri, 23 Feb 2007 11:50:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKdd9-0000Ar-Jo for ram@iab.org; Fri, 23 Feb 2007 11:50:47 -0500 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKdd8-0000hb-47 for ram@iab.org; Fri, 23 Feb 2007 11:50:47 -0500 Received: from asus.online.fr (ver78-2-82-241-91-24.fbx.proxad.net [82.241.91.24]) by smtp7-g19.free.fr (Postfix) with ESMTP id EDFBA15279; Fri, 23 Feb 2007 17:50:36 +0100 (CET) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 23 Feb 2007 17:50:40 +0100 To: Dino Farinacci , "Ricardo V. Oliveira" From: JFC Morfin Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 In-Reply-To: <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070223165036.EDFBA15279@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Generally (a text in preparation) there can be identified three main address layers in everything the human brain considers. - fixity. What is plugged in the earth, geography, networks, gateways... hardware. Routing. - mobility. All what (can) move. Logical management, software. Reaching. - virtuality. at several levels : applications, registries, concepts, etc. intellectual/semantic processing? I proposed an IPv6 solution which would split the IPv6 address container in these three areas, structuring a block /3 namespace to that end. But LISP is more interesting as it can indifferently work for IP4 (and the "a la" existing IPv8 solutions, including NATs) and for IPv6 with an off-the-shelf transparent/reversible migration path. And it can provide much more flexibility in these three domains and any number of sub-domains, and it can support any kind of protocol and datagram load. The main problem is that we have up to now defaulted mobility into fixity. This is probably the time where we will split the single address into location and identity. But we still have to accept that fixity/mobility are issues concerning ISPs in order to provide access to users. This does not really concerns the users, except that they can reach more users. What interests the user is his internal virtuality. In only associating Interface IDs with MAC or any open possibility, we have not yet interested the user. Because nothing has been standardised in terms of local addressing. What is for MAC, what is for plug and play, what is for direct registry interlinking, etc. What LISP makes here, is to warranty that any scheme being developed and used today, will work for ever, because fixity, mobility, and virtualities can each have a full IPv4 or IPv6 addressing space they can freely use and privately standardise - in addition, not instead, of the ports which can resume their full role. Also because the encapsulation/decapsulation step can be associated with a protection scheme to proceed in the namespace below. And it provides a reasonable scheme to adopt whatever IPv12, IPv24, etc. we could devise to address each photon _without_ stopping supporting IPv4. So, it is a real warranty of user stability. jfc At 15:09 23/02/2007, Dino Farinacci wrote: >>>>But if you don't inject EIDs inside the site (like LISPv2), how >>>>are you going to route by EID inside the network? The same >>>>question for the NAT case, how is the NAT box route by EID to the >>>>end host? >>> >>>The EIDs are already inside the site. A site today which is >>>allocated a PI block (or any block for that matter) has their >>>routers, hosts, subnets, and routing protocols already configured >>>with addresses in that block. >>> >>>Remember, this is incremental, EIDs are the host addresses you see >>>today and inside of >>>the site is the addressing you see today. Outside of the site, you >>>use locators which are the addresses you have in BGP today. >>So in the long term, EIDs can be any number, not necessarily >>aligned with the network addresses of routers in the network - they >>reflect the ID of the host. So if > >Yes, that is correct. We will have two namespaces, an EID namespace >and a Locator namespace. The Locator namespace are the IP addresses >and routes we see in the capital-I Internet today. The EID namespace >are the IP addresses that are assigned to hosts and reside in DNS, as >we see it today. > >The split is actually happening topologically, at the site-to-ISP >border. Where the inner addresses are EIDs and used within a site, >and the outer addresses are locators used outside of a source or >destination site. > >I am using the term namespaces because I think this has become the >defacto term among many people I have talked with. > >>the goal is to keep session alive while moving between networks >>(like it's mentioned in the draft) routers inside the any >>destination network must be able to > >Yes, keeping the session alive while doing "slow moves" between >sites. I would consider "fast moves" to be a hand-set roaming from >one part of the topology another part. We are not saying at this >point how well LISP will work in the fast-move scenarios. > >>route to an arbritary EID. Two options: either (1) EIDs are >>injected in IGP or (2) IGP last-hop router address is pushed to >>e.g. DNS to allow routing inside the network... > >Routers route to an arbitrary EID because they know about subnet the >EID is part of. >EIDs are not per say injected. That is the host addresses themselves >are not injected. These EID host addresses are part of a subnet and >are ARP for like things work today. > >We really are not and don't want to change too many things. > >>--Ricardo > >Thanks for the discussion Ricardo. It allows me to be crystal clear >about what our intentions are. I hope people find this valuable and >not noise on the list. > >Dino > >_______________________________________________ >RAM mailing list >RAM@iab.org >https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 23 12:57:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKecO-0008E3-WF; Fri, 23 Feb 2007 12:54:05 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKecH-0007dI-C6 for ram@iab.org; Fri, 23 Feb 2007 12:53:57 -0500 Received: from mailhost.u-strasbg.fr ([2001:660:2402::151]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKeaO-0005Xq-PH for ram@iab.org; Fri, 23 Feb 2007 12:52:02 -0500 Received: from baal.u-strasbg.fr (baal.u-strasbg.fr [IPv6:2001:660:2402::41]) by mailhost.u-strasbg.fr (8.13.8/jtpda-5.5pre1) with ESMTP id l1NHpbSx044788 ; Fri, 23 Feb 2007 18:51:37 +0100 (CET) Received: from [IPv6:2001:660:4701:1001:20d:93ff:fec8:919c] ([IPv6:fe80::215:60ff:feaa:bdf0]) by baal.u-strasbg.fr (8.13.7/jtpda-5.5pre1) with ESMTP id l1NHpbEg077962 ; Fri, 23 Feb 2007 18:51:37 +0100 (CET) Message-ID: <45DF2A62.9080101@crc.u-strasbg.fr> Date: Fri, 23 Feb 2007 18:54:42 +0100 From: Jean-Jacques Pansiot User-Agent: Thunderbird 1.5.0.9 (Macintosh/20061207) MIME-Version: 1.0 To: Dino Farinacci , ram@iab.org Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> In-Reply-To: <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-3.0 (mailhost.u-strasbg.fr [IPv6:2001:660:2402::151]); Fri, 23 Feb 2007 18:51:37 +0100 (CET) X-Virus-Scanned: ClamAV 0.88.7/2631/Thu Feb 22 22:33:11 2007 on mr1.u-strasbg.fr X-Virus-Status: Clean X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,NO_RELAYS autolearn=disabled version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on mr1.u-strasbg.fr X-Spam-Score: -2.8 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, This draft is very interesting. Could you say more on what results are expected from Lisp1 and Lisp1.5 and do you need a very large deployment (at these stages) to reach conclusions ? It seems that true benefits (at least as far as routing table size is concerned) will occur only with Lisp2 or am I missing something ? In Lisp1, where EID are just ordinary IP addresses, do you assume that the ITR inserts a Lisp header for all outgoing packets (in this case what happens if there is no ETR at the destination site ?), or do you expect that the ITR will be configured with a list of "Lisp enabled" foreign prefixes ? Jean-Jacques _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Feb 23 18:24:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKjiA-0000hh-LE; Fri, 23 Feb 2007 18:20:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKji9-0000hC-7x for ram@iab.org; Fri, 23 Feb 2007 18:20:21 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKji7-0000IN-QQ for ram@iab.org; Fri, 23 Feb 2007 18:20:21 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-1.cisco.com with ESMTP; 23 Feb 2007 15:20:18 -0800 X-IronPort-AV: i="4.14,213,1170662400"; d="scan'208"; a="764349430:sNHT47846448" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1NNKHeR002566; Fri, 23 Feb 2007 15:20:17 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1NNK3iA021700; Fri, 23 Feb 2007 15:20:16 -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); Fri, 23 Feb 2007 15:20:06 -0800 Received: from [192.168.0.4] ([10.21.120.145]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 15:20:06 -0800 In-Reply-To: <45DF2A62.9080101@crc.u-strasbg.fr> References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> <45DF2A62.9080101@crc.u-strasbg.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <20293C3B-2D53-4530-8B59-C85F025848E4@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Fri, 23 Feb 2007 11:15:50 -0800 To: Jean-Jacques Pansiot X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Feb 2007 23:20:06.0574 (UTC) FILETIME=[2766ACE0:01C757A1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3499; t=1172272817; x=1173136817; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=fO34CksxHpZjjWDRr1Je001UUu5zEHH3V03wKMax3Wk=; b=vDnn4LsLTA5QsUgOyb59iiz+c5e1RRc6wrIvC7DhUj55x4dwPnNVj2HOSHXpCNKvcDeFLZPb zDfIuezSRRx5diV5RbsU42u/0VyYPJDFLoTngpeJAHCteDiBRRREbEL7; Authentication-Results: sj-dkim-8; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > Hi Dino, > This draft is very interesting. Thanks, but the word that comes to mind for me is "challenging". ;-) > Could you say more on what results are expected from Lisp1 and > Lisp1.5 > and do you need a very large deployment (at these stages) to reach > conclusions ? Well, to test for correctness, we don't need a large deployment, where "large" here means mass deployment (i.e. 100s of sites). We just need to test and understand the different deployment scenarios of ITRs and ETRs as well as seeing how the Locator reachability design works. And I think while doing this, what I want really answered is how much security we really need and last but not least, how much EID namespace aggregation we can get. It would be nice while we deploy if the participating sites could actually withdraw some prefixes from the Locator namespace and infrastructure. I think this will be hard because they will want non- LISP and LISP sites to talk to them. But I poll the operator community to put some cycles to think about this. Also, the ISPs on their own, can play with TE-ITRs and TE-ETRs in their own domains to see if they can withdraw more specifics because they are using tunnels instead. I think we can make more progress here because this community of people and organizations have similar goals/issues. Just thinking out loud. > It seems that true benefits (at least as far as routing table size > is concerned) will > occur only with Lisp2 or am I missing something ? Well, I know everyone is focused on reducing routing table size. But let's not forget some other features LISP can bring. First, you can get site-multihoming where a site can decide how it's packets egress and now (which they couldn't do before) how their packets ingress. Ditto for provider-multihoming and TE, they possible can have more flexibility with tunnels then with longest match routing. > In Lisp1, where EID are just ordinary IP addresses, do you assume > that the ITR In all variants of LISP, the EIDs are ordinary IP addresses. Of course, using this sort of language doesn't really imply that Locators are extraordinary. But I get what you are inferring. > inserts a Lisp header for all outgoing packets The ITR prepends a header for traffic that is globllay addressed. If the destination address is local to the site, the ITR is just a plain- ole-router which L2 encaps and sends the packet on it's way toward the local destination. > (in this case what happens if there is no ETR at the destination > site ?), Well, good point. If the outer header is a locator, you will get an ICMP unreachable because the ETR is not there. But one first must ask, how did you get that Locator. If it was configured, in a LISP 2 or LISP 3 case, then this could happen. In a LISP 1 and LISP 1.5 (when globally routable EIDs exist), the outer destination address is the host itself. So the host would receive the packet. It will send a protocol unreachable because it won't know how to decapsulate. So it falls under the same former case. > or do you expect that the ITR will be configured with a list of > "Lisp enabled" foreign prefixes ? I'm trying to decide if I should implement static EID-prefix routes, not sure that is a good thing (it makes things flexible) or bad thing (we could cause the issues you raise). Any opinions out there? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 05:07:06 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLcga-0004I0-A8; Mon, 26 Feb 2007 05:02:24 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLcgJ-0004AI-9R for ram@iab.org; Mon, 26 Feb 2007 05:02:07 -0500 Received: from [2a01:d0::6:2] (helo=netassist.kiev.ua) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLcR4-0004zh-HY for ram@iab.org; Mon, 26 Feb 2007 04:46:27 -0500 Received: from [195.214.215.3] by netassist.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60 and XAMS 0.0.13) id 1HLc9c-0007nh-QS for ram@iab.org; Mon, 26 Feb 2007 11:28:20 +0200 Message-ID: <45E2C884.8080909@netassist.kiev.ua> Date: Mon, 26 Feb 2007 11:46:12 +0000 From: Max Tulyev User-Agent: Thunderbird 1.5.0.8 (X11/20061123) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types References: <001001c73b0c$64156ac0$351975c2@Globo> In-Reply-To: <001001c73b0c$64156ac0$351975c2@Globo> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi all, The main idea of FQDN-based multihoming is a patched DNS server with TTL always 1 in replies. FQDN is not a subject of change, but IP to resolve to is. The DNS server resolves host to IP not only using name of this host, but using other information such as IP of requestor, table of really working interfaces, current load of interfaces and so. Disadvantages of this is all currently active sessions will be dropped when one of channels will go down, and also DNS replies can not be cached. Advantages is we don't need to alter the world to implement it. We can do it right now. There is many implementations of this schema near me, including for VoIP. All of them working reasonable for real business. Rui Campos wrote: > Hi all, > > I have been following the discussions in this list and I just would like to > comment this FQDN issue. > > IMHO, even if FQDNs are used as identifiers for hosts things will not work > properly, at least without modifying the way FQDN assignment works in the > current Internet (probably that's the your idea, I'm not sure). > > Let's consider a host H that attaches itself to different domains along the > time. While H is attached to the same domain (e.g., domain1.com.) its FQDN > does not change. Then, H can be uniquely identified by a peer host even if its > IP address changes, assuming that the mapping FQDN <-> IP address is handled > properly. However, when H moves between different domains the FQDN will change > at the same pace. For instance, at instant 1 H gets connected to domain1.com > and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and its > FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to > domain3 and its FQDN becomes "H.domain3.com". Therefore, every session bound > to an FQDN will break when the host moves from one domain to the other. On the > other hand, how does a peer host will get informed about the current host's > FQDN? > > If we consider multi-homed hosts (i.e., hosts with multiple network > interfaces) the problem is even exacerbated. In fact, multi-homed hosts may > have an FQDN per network interface. Then, what FQDN will a peer host use to > contact a multi-homed host? There is not a single FQDN that uniquely > identifies the host regardless of its location and number of network > interfaces. > > BR, > Rui Campos _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 06:18:05 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLdoe-0001PT-Vy; Mon, 26 Feb 2007 06:14:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLdoe-0001PN-6E for ram@iab.org; Mon, 26 Feb 2007 06:14:48 -0500 Received: from clifford.inescn.pt ([192.35.246.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLdoc-0000y6-4t for ram@iab.org; Mon, 26 Feb 2007 06:14:48 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by clifford.inescn.pt (8.13.8/8.13.8/1) with ESMTP id l1QBEggS020518; Mon, 26 Feb 2007 11:14:42 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from clifford.inescn.pt ([127.0.0.1]) by localhost (clifford.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 59f0ydpkH6Go; Mon, 26 Feb 2007 11:14:23 +0000 (WET) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by clifford.inescn.pt (8.13.8/8.13.8/9) with ESMTP id l1QBAZSC020270; Mon, 26 Feb 2007 11:10:35 GMT Received: from Globo (keskonrix.inescn.pt [194.117.26.120]) by pong.inescporto.pt (Postfix) with ESMTP id 82BB013CDE7; Mon, 26 Feb 2007 11:10:35 +0000 (WET) From: "Rui Campos" To: "'Max Tulyev'" , Subject: RE: [RAM] candidate properties of some new name types Date: Mon, 26 Feb 2007 11:10:35 -0000 Message-ID: <019101c75996$bd200ff0$351975c2@Globo> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 In-Reply-To: <45E2C884.8080909@netassist.kiev.ua> Thread-Index: AcdZjrPKT7qsXHA6SVebQjzQ5OecmgABg/cw X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: a8041eca2a724d631b098c15e9048ce9 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1870902911==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============1870902911== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; boundary="----=_NextPart_000_018C_01C75996.BC7B9290"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_018C_01C75996.BC7B9290 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Max Tulyev, See my comments inline. Thanks! BR, Rui Campos -----Original Message----- From: Max Tulyev [mailto:maxtul@netassist.kiev.ua] Sent: segunda-feira, 26 de Fevereiro de 2007 11:46 To: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types Hi all, The main idea of FQDN-based multihoming is a patched DNS server with TTL always 1 in replies. FQDN is not a subject of change, but IP to resolve to is. [Rui Campos] Are you really considering the scenario I have mentioned in my e-mail below? I know that the FQDN will not change if a host stays connected within the same domain. But, what about the scenario where you jump from domain to domain? This does not seem to be supported by the mechanism you are talking about, unless I am missing something here ;-) The DNS server resolves host to IP not only using name of this host, but using other information such as IP of requestor, table of really working interfaces, current load of interfaces and so. [Rui Campos] Doesn't this mean modification of the world? :-) As far as I know, today DNS servers do not consider all these parameters for resolving host to IP. Disadvantages of this is all currently active sessions will be dropped when one of channels will go down, and also DNS replies can not be cached. Advantages is we don't need to alter the world to implement it. We can do it right now. [Rui Campos] Are you sure you don't need to change the "DNS world" as we know it today? There is many implementations of this schema near me, including for VoIP. All of them working reasonable for real business. [Rui Campos] I understand that this can work for local scenarios, as I have mentioned above. But I doubt it would work in a global scope without modifying the "DNS world" ;-) Rui Campos wrote: > Hi all, > > I have been following the discussions in this list and I just would like to > comment this FQDN issue. > > IMHO, even if FQDNs are used as identifiers for hosts things will not work > properly, at least without modifying the way FQDN assignment works in the > current Internet (probably that's the your idea, I'm not sure). > > Let's consider a host H that attaches itself to different domains along the > time. While H is attached to the same domain (e.g., domain1.com.) its FQDN > does not change. Then, H can be uniquely identified by a peer host even if its > IP address changes, assuming that the mapping FQDN <-> IP address is handled > properly. However, when H moves between different domains the FQDN will change > at the same pace. For instance, at instant 1 H gets connected to domain1.com > and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and its > FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to > domain3 and its FQDN becomes "H.domain3.com". Therefore, every session bound > to an FQDN will break when the host moves from one domain to the other. On the > other hand, how does a peer host will get informed about the current host's > FQDN? > > If we consider multi-homed hosts (i.e., hosts with multiple network > interfaces) the problem is even exacerbated. In fact, multi-homed hosts may > have an FQDN per network interface. Then, what FQDN will a peer host use to > contact a multi-homed host? There is not a single FQDN that uniquely > identifies the host regardless of its location and number of network > interfaces. > > BR, > Rui Campos _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.3/699 - Release Date: 23-02-2007 13:26 ------=_NextPart_000_018C_01C75996.BC7B9290 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOFTCCBlkw ggRBoAMCAQICASMwDQYJKoZIhvcNAQEFBQAwejELMAkGA1UEBhMCUFQxFDASBgNVBAoTC0lORVND IFBvcnRvMQwwCgYDVQQLEwNVVE0xHzAdBgNVBAMTFklORVNDIFBvcnRvIC0gVVRNIC0gQ0ExJjAk BgkqhkiG9w0BCQEWF2NhbWFuYWdlckBpbmVzY3BvcnRvLnB0MB4XDTA2MDQxMjIwMzQ0M1oXDTA3 MDQxMjIwMzQ0M1owgZcxCzAJBgNVBAYTAlBUMRMwEQYDVQQDEwpSdWkgQ2FtcG9zMTIwMAYDVQQL EylDb21tdW5pY2F0aW9uIE5ldHdvcmtzIGFuZCBTZXJ2aWNlcyBHcm91cDEMMAoGA1UECxMDVVRN MRQwEgYDVQQKEwtJTkVTQyBQb3J0bzEOMAwGA1UEBxMFUG9ydG8xCzAJBgNVBAUTAjM1MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCS2YXjry7ovnvZvKE9cLo7e2r9OMmJQvw+1KrIjVkM/9fr R99M4CKYWaC2rjTowrR8b2qNifN3hSvhPkFi2/9Hop1PNquD/BW+RdagwLDhf3dz9rhoJeWtAXq8 B/8aBU+TQtFcjLXWvZTilZ1KtVSVkLTM22nTd31TeHANmjUHfQIDAQABo4ICTjCCAkowCQYDVR0T BAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNxQCAjAuBglghkgBhvhCAQ0EIRYfVXNlciBDZXJ0aWZpY2F0ZSBv ZiBJTkVTQyBQb3J0bzAdBgNVHQ4EFgQUngwWtz0W91KkxriNNq1H5cszxj4wgawGA1UdIwSBpDCB oYAU8gsrHnNGEQNPNZjAmg14KoqtJsihfqR8MHoxCzAJBgNVBAYTAlBUMRQwEgYDVQQKEwtJTkVT QyBQb3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAtIFVUTSAtIENBMSYw JAYJKoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdIIJAMSy6A7w3RlCMCAGA1UdEQQZ MBeBFXJjYW1wb3NAaW5lc2Nwb3J0by5wdDAiBgNVHRIEGzAZgRdjYW1hbmFnZXJAaW5lc2Nwb3J0 by5wdDA4BglghkgBhvhCAQQEKxYpaHR0cDovL3JhLmluZXNjcG9ydG8ucHQvcHViL2NybC9jYWNy bC5jcmwwOAYJYIZIAYb4QgEDBCsWKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwvY2Fj cmwuY3JsMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwv Y2FjcmwuY3JsMA0GCSqGSIb3DQEBBQUAA4ICAQCVHY7N2+xLb93mIrUY15stGEDNgGwlijil/QF6 LhYTFlw4plTT+Dw6UUuKTJIsCVj6uc2FVKBJLXOo8v55ZQYCioi0Lx/GWPRHZ27kwim+BkTIR7OH Mb0cU+yYjEhmCshJBtU2VmSsy3bU2EyjHqbUGEhTUSiFNBXLrkEXC3ubSKvGRY7UR6wZZFOT04V3 DhjKm4nlvZ65dp0/PglSGB0Y+gFwp6yRT4tQ3swGPb13iBreUnPMXyA9boeRF6wVNJIZEzQzUpPq /gXNzdMPsbo/5w09NAn0QaiGP0LaCizBQDGB91/LC7LyfpIY4DKWWaw4TGDWU5vweo3KMdhnoBuM tkMC0/9yxHXqfLrf35q7eBv01KhmIj+qfV3NWgtVVJczQxjtv97g9tjOTYMhEYOLInP82i7jUAEu 3bgn2lP23g0xJXgNGJzQ53s8SvAbp6r0vYpOCie/UAz0FV/aH9ffaZf8sHxEkk5x6k6SPp2FfsD9 CpQ8HqiJtjTX2gw3DEIGzDzcaZQ1OZz+5IjbWtmGvKhbT2dwNckKEt16fmnLgnlBxizwtoMKkMe8 4+xvA/B2M/EGhNYcO0qUGe6tMlMEESQqR3/uBmo1leTA6A9aMC6sPFMO1NCesX3MU+PDCT96/yie LGa+EQwYKQxhHFuvK7O/rI+pG8zcqPmD7iFGRzCCB7QwggWcoAMCAQICCQDEsugO8N0ZQjANBgkq hkiG9w0BAQUFADB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAKBgNVBAsT A1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJARYXY2Ft YW5hZ2VyQGluZXNjcG9ydG8ucHQwHhcNMDUwNjE5MTQxNDEwWhcNMjUwNjE0MTQxNDEwWjB6MQsw CQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAKBgNVBAsTA1VUTTEfMB0GA1UEAxMW SU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJARYXY2FtYW5hZ2VyQGluZXNjcG9y dG8ucHQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCd0K8k93BTIHVOeXdtuBf9fY7w wyDUsi0z5B4ma5V3w0Pve2Sb4H2NYu4XVrzqMP/DPX3LmPvoaBXsNFvhyoxr0Aa+fpQB5tO7zlVl jdM5mhWo9lvM8v6r6UEoadBoR6gm/Fc/mybZlH8QaACWPTLYwSXdONvd60hR72m5V4m3RHmyWSs6 ruUPDI0BEgU2fBgiykqQM87QGLXkWz5t7L2Ty0PLNb5+dkNGSWA+6eYViqq1qd+vgVq/biRCqt/m xvrjnbOOnTsU2FQlxXzK5n+CFpr4YMlQISXKz2hqlwO+rcK5sW8gQ/UbgqNPuqwejqrsz62ShyXd 6UFP3kDtHLBwV6SrJy1husupYqdDcdLrDHXs1iRq6JdWc6gFusolRicXEglmSYbnazAkuq/lO+xn xUWMN5fXrk9FqwUFBVHKFJ+BsDmqimBKT8IMlXI0xFq7N/7ASpFNH/2jc9zy6ybdJbDO3a7x7mWC 1VIFfZDl+Cly8z/JbF5bc2ZUkIm2GnjM7s12nR7tDwRxeJV4SgYfoB2/oYFzMfSPegHatFrpyQYh wD8BDW4IZMf9eR9iG1foNOeS8kx4K7ecSF/PhOdvxyuS4ZTDaAr4QDNzZhROuQna1tAilYb5hQIY HzR0/L3Zm9x+cXQAMzJeWB5Cuviafz4VDROw7l2AZNbptUQ1BQIDAQABo4ICOzCCAjcwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU8gsrHnNGEQNPNZjAmg14KoqtJsgwgawGA1UdIwSBpDCBoYAU 8gsrHnNGEQNPNZjAmg14KoqtJsihfqR8MHoxCzAJBgNVBAYTAlBUMRQwEgYDVQQKEwtJTkVTQyBQ b3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAtIFVUTSAtIENBMSYwJAYJ KoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdIIJAMSy6A7w3RlCMAsGA1UdDwQEAwIB BjAiBgNVHREEGzAZgRdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdDAiBgNVHRIEGzAZgRdjYW1hbmFn ZXJAaW5lc2Nwb3J0by5wdDARBglghkgBhvhCAQEEBAMCAAcwPgYJYIZIAYb4QgENBDEWL0lORVND IFBvcnRvIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IENlcnRpZmljYXRlMDoGA1UdHwQzMDEwL6At oCuGKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwvY2FjcmwuY3JsMDgGCWCGSAGG+EIB BAQrFilodHRwOi8vcmEuaW5lc2Nwb3J0by5wdC9wdWIvY3JsL2NhY3JsLmNybDA4BglghkgBhvhC AQMEKxYpaHR0cDovL3JhLmluZXNjcG9ydG8ucHQvcHViL2NybC9jYWNybC5jcmwwDQYJKoZIhvcN AQEFBQADggIBAGT5Id7wFvMAuow44xm8oDDEgw94+HwFCiTKTNA9Xa5fO7QjKGWQCe+rXi69q2cy TW598Kgs4pdwQ8oHNEGIuCpIUjpBc1YH7M/injXlnBKK7XOw1/pBEu79lPJvMFS5Lf5NlRIEJW2x tBvduSbRNUB3DZ7RWXMthhMu0WoN94O4TRukNNioeK8thy6C0ch45d1LoVsNylY+KpoV0IFi4efS UY1wkJPrEsTDeeUQZGeqG679ycp3H/5N9NSg7cpFTom3k9M0+ICqvdIZYQCg/XczM/PWTC2hnqbZ o1ppSIF0dgFoZ4VpggjPs3d2MvQzVDELRclgp4/082PI3jgtbieBz5BKvSOh7DrEUdGpY4DJ4A6J Gz94BAnpNCjy0qLIrd/+2GyFCakvzl+ggVcx7ZhapkqBrEXuHA311YxtTOHSJeWDvnnbPUXOf3r+ 30m3VtVFKvwJ/i1EW39cDLpSX9Ny04zRaAbczp3I1eZe4Xjgh1atgAxQxS4SmArcCaI4583U4vcE s+skeJQXCuMO9JwrtNR4ZNSiaAnNYZbVlguHeQ+cKjTrjxYn3agkbJoJDFEHw2YRrpBqZcdwS2ZO Ud4ThL7DtkBEcKWzCd0aFNSR67NAwsiBALv1h1MCwr2RRN96ltvtXH9izDL52h8btdbknqAxT9us nUELzIjgG+fPMYIDFTCCAxECAQEwfzB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9y dG8xDDAKBgNVBAsTA1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqG SIb3DQEJARYXY2FtYW5hZ2VyQGluZXNjcG9ydG8ucHQCASMwCQYFKw4DAhoFAKCCAewwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjI2MTExMDM0WjAjBgkqhkiG 9w0BCQQxFgQUWo4gSizqX2V7bx8ICjqJKSo6dJ4wZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgY8GCSsGAQQBgjcQBDGBgTB/MHoxCzAJBgNVBAYTAlBUMRQw EgYDVQQKEwtJTkVTQyBQb3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAt IFVUTSAtIENBMSYwJAYJKoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdAIBIzCBkQYL KoZIhvcNAQkQAgsxgYGgfzB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAK BgNVBAsTA1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJ ARYXY2FtYW5hZ2VyQGluZXNjcG9ydG8ucHQCASMwDQYJKoZIhvcNAQEBBQAEgYAmtbcETRe26JLv 1o5fyLlBVvJwHxNdqseDiZ5A+WId9PmdhFySV7UtQNZb6pZuoaqOW04USarvws7NX3QfP5jC8RPq F+PMJCtQqfUCQUR0vdFMAb44tMl5kI6lLZ8kAGdF3Yt9qVkW6x4mh7LtyOkpQkYStRZ/0Yj4I/p1 cwhRxgAAAAAAAA== ------=_NextPart_000_018C_01C75996.BC7B9290-- --===============1870902911== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1870902911==-- From ram-bounces@iab.org Mon Feb 26 10:40:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhwZ-0007eM-2A; Mon, 26 Feb 2007 10:39:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLhwV-0007dH-Bn for ram@iab.org; Mon, 26 Feb 2007 10:39:12 -0500 Received: from [2a01:d0::6:2] (helo=netassist.kiev.ua) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLhwR-0001g9-F9 for ram@iab.org; Mon, 26 Feb 2007 10:39:11 -0500 Received: from [2a01:d0::11:1] by netassist.kiev.ua with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.60 and XAMS 0.0.13) id 1HLhew-0006VS-0n; Mon, 26 Feb 2007 17:21:02 +0200 Message-ID: <45E2FF38.70508@netassist.kiev.ua> Date: Mon, 26 Feb 2007 17:39:36 +0200 From: Max Tulyev User-Agent: Thunderbird 1.5.0.8 (X11/20061224) MIME-Version: 1.0 To: Rui Campos Subject: Re: [RAM] candidate properties of some new name types References: <019101c75996$bd200ff0$351975c2@Globo> In-Reply-To: <019101c75996$bd200ff0$351975c2@Globo> X-Enigmail-Version: 0.94.1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.8 (--) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Rui, Rui Campos wrote: > The main idea of FQDN-based multihoming is a patched DNS server with TTL > always 1 in replies. FQDN is not a subject of change, but IP to resolve > to is. > [Rui Campos] Are you really considering the scenario I have mentioned in my > e-mail below? I know that the FQDN will not change if a host stays connected > within the same domain. But, what about the scenario where you jump from > domain to domain? This does not seem to be supported by the mechanism you > are talking about, unless I am missing something here ;-) Yes, your scenario really differs from mine ;) > > The DNS server resolves host to IP not only using name of this host, but > using other information such as IP of requestor, table of really working > interfaces, current load of interfaces and so. > [Rui Campos] Doesn't this mean modification of the world? :-) As far as I > know, today DNS servers do not consider all these parameters for resolving > host to IP. Yes, it means no modification to the world, it is fully compatible with things running now. You should alter only YOUR DNS servers, not all in the world. Or even to start up to provide such service to other. But the main thing - we don't need to alter all the world (i.e. all routers in the world and so), as if implementing other non-PI multihoming schemas (as I can understand this). > > Disadvantages of this is all currently active sessions will be dropped > when one of channels will go down, and also DNS replies can not be cached. > > Advantages is we don't need to alter the world to implement it. We can > do it right now. > [Rui Campos] Are you sure you don't need to change the "DNS world" as we > know it today? Really. Only your DNS serving your multihoming domain. Let's look again. We have www.foo.com with two interfaces, 10.0.0.1 and 192.168.0.1. Let's serve A answer 10.0.0.1 (or both) until it is alive. If 10.0.0.1 went down (i.e. stop pinging in my case) - we continue serve 192.168.0.1 in replies instead. To prevent replies to be cached by caching resolvers (and traffic flow to unconnected interface), let's set TTL in the domain to 1 sec. In my case all of that implemented only with Bash scripting and named. > > There is many implementations of this schema near me, including for > VoIP. All of them working reasonable for real business. > [Rui Campos] I understand that this can work for local scenarios, as I have > mentioned above. But I doubt it would work in a global scope without > modifying the "DNS world" ;-) TTL=1 really helps ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 11:20:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLiZ4-0003UH-Uq; Mon, 26 Feb 2007 11:19:02 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLiX5-0002mi-AA for ram@iab.org; Mon, 26 Feb 2007 11:16:59 -0500 Received: from clifford.inescn.pt ([192.35.246.3]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLiJ5-0004xo-HJ for ram@iab.org; Mon, 26 Feb 2007 11:02:33 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by clifford.inescn.pt (8.13.8/8.13.8/1) with ESMTP id l1QG2Rgx004956; Mon, 26 Feb 2007 16:02:27 GMT X-Virus-Scanned: amavisd-new at inescporto.pt Received: from clifford.inescn.pt ([127.0.0.1]) by localhost (clifford.inescn.pt [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GQ7zvjCpn7t2; Mon, 26 Feb 2007 16:02:15 +0000 (WET) Received: from pong.inescporto.pt (pong.inescn.pt [194.117.26.74]) by clifford.inescn.pt (8.13.8/8.13.8/9) with ESMTP id l1QG1eFm004901; Mon, 26 Feb 2007 16:01:40 GMT Received: from Globo (keskonrix.inescn.pt [194.117.26.120]) by pong.inescporto.pt (Postfix) with ESMTP id 8FDC1174F64; Mon, 26 Feb 2007 16:01:40 +0000 (WET) From: "Rui Campos" To: "'Max Tulyev'" Subject: RE: [RAM] candidate properties of some new name types Date: Mon, 26 Feb 2007 16:01:39 -0000 MIME-Version: 1.0 Message-ID: <000501c759bf$66c65cd0$781a75c2@Globo> X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdZvF4NlLAjrAu2RfyKyYsg8ZHGhwAAlaJw In-Reply-To: <45E2FF38.70508@netassist.kiev.ua> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 X-Spam-Score: 0.1 (/) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1229063628==" Errors-To: ram-bounces@iab.org This is a multi-part message in MIME format. --===============1229063628== Content-Type: multipart/signed; boundary="----=_NextPart_000_0000_01C759BF.63AEBC90"; protocol="application/x-pkcs7-signature"; micalg=SHA1 This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C759BF.63AEBC90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Max, Thanks for your reply! Now I confirm that you were considering a different scenario. Then, I can agree with your statements ;-) BR, Rui Campos -----Original Message----- From: Max Tulyev [mailto:maxtul@netassist.kiev.ua] Sent: segunda-feira, 26 de Fevereiro de 2007 15:40 To: Rui Campos Cc: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types Hi Rui, Rui Campos wrote: > The main idea of FQDN-based multihoming is a patched DNS server with TTL > always 1 in replies. FQDN is not a subject of change, but IP to resolve > to is. > [Rui Campos] Are you really considering the scenario I have mentioned in my > e-mail below? I know that the FQDN will not change if a host stays connected > within the same domain. But, what about the scenario where you jump from > domain to domain? This does not seem to be supported by the mechanism you > are talking about, unless I am missing something here ;-) Yes, your scenario really differs from mine ;) > > The DNS server resolves host to IP not only using name of this host, but > using other information such as IP of requestor, table of really working > interfaces, current load of interfaces and so. > [Rui Campos] Doesn't this mean modification of the world? :-) As far as I > know, today DNS servers do not consider all these parameters for resolving > host to IP. Yes, it means no modification to the world, it is fully compatible with things running now. You should alter only YOUR DNS servers, not all in the world. Or even to start up to provide such service to other. But the main thing - we don't need to alter all the world (i.e. all routers in the world and so), as if implementing other non-PI multihoming schemas (as I can understand this). > > Disadvantages of this is all currently active sessions will be dropped > when one of channels will go down, and also DNS replies can not be cached. > > Advantages is we don't need to alter the world to implement it. We can > do it right now. > [Rui Campos] Are you sure you don't need to change the "DNS world" as we > know it today? Really. Only your DNS serving your multihoming domain. Let's look again. We have www.foo.com with two interfaces, 10.0.0.1 and 192.168.0.1. Let's serve A answer 10.0.0.1 (or both) until it is alive. If 10.0.0.1 went down (i.e. stop pinging in my case) - we continue serve 192.168.0.1 in replies instead. To prevent replies to be cached by caching resolvers (and traffic flow to unconnected interface), let's set TTL in the domain to 1 sec. In my case all of that implemented only with Bash scripting and named. > > There is many implementations of this schema near me, including for > VoIP. All of them working reasonable for real business. > [Rui Campos] I understand that this can work for local scenarios, as I have > mentioned above. But I doubt it would work in a global scope without > modifying the "DNS world" ;-) TTL=1 really helps ;) -- WBR, Max Tulyev (MT6561-RIPE, 2:463/253@FIDO) -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.441 / Virus Database: 268.18.3/699 - Release Date: 23-02-2007 13:26 ------=_NextPart_000_0000_01C759BF.63AEBC90 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOFTCCBlkw ggRBoAMCAQICASMwDQYJKoZIhvcNAQEFBQAwejELMAkGA1UEBhMCUFQxFDASBgNVBAoTC0lORVND IFBvcnRvMQwwCgYDVQQLEwNVVE0xHzAdBgNVBAMTFklORVNDIFBvcnRvIC0gVVRNIC0gQ0ExJjAk BgkqhkiG9w0BCQEWF2NhbWFuYWdlckBpbmVzY3BvcnRvLnB0MB4XDTA2MDQxMjIwMzQ0M1oXDTA3 MDQxMjIwMzQ0M1owgZcxCzAJBgNVBAYTAlBUMRMwEQYDVQQDEwpSdWkgQ2FtcG9zMTIwMAYDVQQL EylDb21tdW5pY2F0aW9uIE5ldHdvcmtzIGFuZCBTZXJ2aWNlcyBHcm91cDEMMAoGA1UECxMDVVRN MRQwEgYDVQQKEwtJTkVTQyBQb3J0bzEOMAwGA1UEBxMFUG9ydG8xCzAJBgNVBAUTAjM1MIGfMA0G CSqGSIb3DQEBAQUAA4GNADCBiQKBgQCS2YXjry7ovnvZvKE9cLo7e2r9OMmJQvw+1KrIjVkM/9fr R99M4CKYWaC2rjTowrR8b2qNifN3hSvhPkFi2/9Hop1PNquD/BW+RdagwLDhf3dz9rhoJeWtAXq8 B/8aBU+TQtFcjLXWvZTilZ1KtVSVkLTM22nTd31TeHANmjUHfQIDAQABo4ICTjCCAkowCQYDVR0T BAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCkGA1UdJQQiMCAGCCsGAQUFBwMC BggrBgEFBQcDBAYKKwYBBAGCNxQCAjAuBglghkgBhvhCAQ0EIRYfVXNlciBDZXJ0aWZpY2F0ZSBv ZiBJTkVTQyBQb3J0bzAdBgNVHQ4EFgQUngwWtz0W91KkxriNNq1H5cszxj4wgawGA1UdIwSBpDCB oYAU8gsrHnNGEQNPNZjAmg14KoqtJsihfqR8MHoxCzAJBgNVBAYTAlBUMRQwEgYDVQQKEwtJTkVT QyBQb3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAtIFVUTSAtIENBMSYw JAYJKoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdIIJAMSy6A7w3RlCMCAGA1UdEQQZ MBeBFXJjYW1wb3NAaW5lc2Nwb3J0by5wdDAiBgNVHRIEGzAZgRdjYW1hbmFnZXJAaW5lc2Nwb3J0 by5wdDA4BglghkgBhvhCAQQEKxYpaHR0cDovL3JhLmluZXNjcG9ydG8ucHQvcHViL2NybC9jYWNy bC5jcmwwOAYJYIZIAYb4QgEDBCsWKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwvY2Fj cmwuY3JsMDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwv Y2FjcmwuY3JsMA0GCSqGSIb3DQEBBQUAA4ICAQCVHY7N2+xLb93mIrUY15stGEDNgGwlijil/QF6 LhYTFlw4plTT+Dw6UUuKTJIsCVj6uc2FVKBJLXOo8v55ZQYCioi0Lx/GWPRHZ27kwim+BkTIR7OH Mb0cU+yYjEhmCshJBtU2VmSsy3bU2EyjHqbUGEhTUSiFNBXLrkEXC3ubSKvGRY7UR6wZZFOT04V3 DhjKm4nlvZ65dp0/PglSGB0Y+gFwp6yRT4tQ3swGPb13iBreUnPMXyA9boeRF6wVNJIZEzQzUpPq /gXNzdMPsbo/5w09NAn0QaiGP0LaCizBQDGB91/LC7LyfpIY4DKWWaw4TGDWU5vweo3KMdhnoBuM tkMC0/9yxHXqfLrf35q7eBv01KhmIj+qfV3NWgtVVJczQxjtv97g9tjOTYMhEYOLInP82i7jUAEu 3bgn2lP23g0xJXgNGJzQ53s8SvAbp6r0vYpOCie/UAz0FV/aH9ffaZf8sHxEkk5x6k6SPp2FfsD9 CpQ8HqiJtjTX2gw3DEIGzDzcaZQ1OZz+5IjbWtmGvKhbT2dwNckKEt16fmnLgnlBxizwtoMKkMe8 4+xvA/B2M/EGhNYcO0qUGe6tMlMEESQqR3/uBmo1leTA6A9aMC6sPFMO1NCesX3MU+PDCT96/yie LGa+EQwYKQxhHFuvK7O/rI+pG8zcqPmD7iFGRzCCB7QwggWcoAMCAQICCQDEsugO8N0ZQjANBgkq hkiG9w0BAQUFADB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAKBgNVBAsT A1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJARYXY2Ft YW5hZ2VyQGluZXNjcG9ydG8ucHQwHhcNMDUwNjE5MTQxNDEwWhcNMjUwNjE0MTQxNDEwWjB6MQsw CQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAKBgNVBAsTA1VUTTEfMB0GA1UEAxMW SU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJARYXY2FtYW5hZ2VyQGluZXNjcG9y dG8ucHQwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQCd0K8k93BTIHVOeXdtuBf9fY7w wyDUsi0z5B4ma5V3w0Pve2Sb4H2NYu4XVrzqMP/DPX3LmPvoaBXsNFvhyoxr0Aa+fpQB5tO7zlVl jdM5mhWo9lvM8v6r6UEoadBoR6gm/Fc/mybZlH8QaACWPTLYwSXdONvd60hR72m5V4m3RHmyWSs6 ruUPDI0BEgU2fBgiykqQM87QGLXkWz5t7L2Ty0PLNb5+dkNGSWA+6eYViqq1qd+vgVq/biRCqt/m xvrjnbOOnTsU2FQlxXzK5n+CFpr4YMlQISXKz2hqlwO+rcK5sW8gQ/UbgqNPuqwejqrsz62ShyXd 6UFP3kDtHLBwV6SrJy1husupYqdDcdLrDHXs1iRq6JdWc6gFusolRicXEglmSYbnazAkuq/lO+xn xUWMN5fXrk9FqwUFBVHKFJ+BsDmqimBKT8IMlXI0xFq7N/7ASpFNH/2jc9zy6ybdJbDO3a7x7mWC 1VIFfZDl+Cly8z/JbF5bc2ZUkIm2GnjM7s12nR7tDwRxeJV4SgYfoB2/oYFzMfSPegHatFrpyQYh wD8BDW4IZMf9eR9iG1foNOeS8kx4K7ecSF/PhOdvxyuS4ZTDaAr4QDNzZhROuQna1tAilYb5hQIY HzR0/L3Zm9x+cXQAMzJeWB5Cuviafz4VDROw7l2AZNbptUQ1BQIDAQABo4ICOzCCAjcwDwYDVR0T AQH/BAUwAwEB/zAdBgNVHQ4EFgQU8gsrHnNGEQNPNZjAmg14KoqtJsgwgawGA1UdIwSBpDCBoYAU 8gsrHnNGEQNPNZjAmg14KoqtJsihfqR8MHoxCzAJBgNVBAYTAlBUMRQwEgYDVQQKEwtJTkVTQyBQ b3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAtIFVUTSAtIENBMSYwJAYJ KoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdIIJAMSy6A7w3RlCMAsGA1UdDwQEAwIB BjAiBgNVHREEGzAZgRdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdDAiBgNVHRIEGzAZgRdjYW1hbmFn ZXJAaW5lc2Nwb3J0by5wdDARBglghkgBhvhCAQEEBAMCAAcwPgYJYIZIAYb4QgENBDEWL0lORVND IFBvcnRvIENlcnRpZmljYXRpb24gQXV0aG9yaXR5IENlcnRpZmljYXRlMDoGA1UdHwQzMDEwL6At oCuGKWh0dHA6Ly9yYS5pbmVzY3BvcnRvLnB0L3B1Yi9jcmwvY2FjcmwuY3JsMDgGCWCGSAGG+EIB BAQrFilodHRwOi8vcmEuaW5lc2Nwb3J0by5wdC9wdWIvY3JsL2NhY3JsLmNybDA4BglghkgBhvhC AQMEKxYpaHR0cDovL3JhLmluZXNjcG9ydG8ucHQvcHViL2NybC9jYWNybC5jcmwwDQYJKoZIhvcN AQEFBQADggIBAGT5Id7wFvMAuow44xm8oDDEgw94+HwFCiTKTNA9Xa5fO7QjKGWQCe+rXi69q2cy TW598Kgs4pdwQ8oHNEGIuCpIUjpBc1YH7M/injXlnBKK7XOw1/pBEu79lPJvMFS5Lf5NlRIEJW2x tBvduSbRNUB3DZ7RWXMthhMu0WoN94O4TRukNNioeK8thy6C0ch45d1LoVsNylY+KpoV0IFi4efS UY1wkJPrEsTDeeUQZGeqG679ycp3H/5N9NSg7cpFTom3k9M0+ICqvdIZYQCg/XczM/PWTC2hnqbZ o1ppSIF0dgFoZ4VpggjPs3d2MvQzVDELRclgp4/082PI3jgtbieBz5BKvSOh7DrEUdGpY4DJ4A6J Gz94BAnpNCjy0qLIrd/+2GyFCakvzl+ggVcx7ZhapkqBrEXuHA311YxtTOHSJeWDvnnbPUXOf3r+ 30m3VtVFKvwJ/i1EW39cDLpSX9Ny04zRaAbczp3I1eZe4Xjgh1atgAxQxS4SmArcCaI4583U4vcE s+skeJQXCuMO9JwrtNR4ZNSiaAnNYZbVlguHeQ+cKjTrjxYn3agkbJoJDFEHw2YRrpBqZcdwS2ZO Ud4ThL7DtkBEcKWzCd0aFNSR67NAwsiBALv1h1MCwr2RRN96ltvtXH9izDL52h8btdbknqAxT9us nUELzIjgG+fPMYIDFTCCAxECAQEwfzB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9y dG8xDDAKBgNVBAsTA1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqG SIb3DQEJARYXY2FtYW5hZ2VyQGluZXNjcG9ydG8ucHQCASMwCQYFKw4DAhoFAKCCAewwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDcwMjI2MTYwMTM0WjAjBgkqhkiG 9w0BCQQxFgQUsLYDWwzllQeEIS9AzEAh+/96hZAwZwYJKoZIhvcNAQkPMVowWDAKBggqhkiG9w0D BzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgw BwYFKw4DAhowCgYIKoZIhvcNAgUwgY8GCSsGAQQBgjcQBDGBgTB/MHoxCzAJBgNVBAYTAlBUMRQw EgYDVQQKEwtJTkVTQyBQb3J0bzEMMAoGA1UECxMDVVRNMR8wHQYDVQQDExZJTkVTQyBQb3J0byAt IFVUTSAtIENBMSYwJAYJKoZIhvcNAQkBFhdjYW1hbmFnZXJAaW5lc2Nwb3J0by5wdAIBIzCBkQYL KoZIhvcNAQkQAgsxgYGgfzB6MQswCQYDVQQGEwJQVDEUMBIGA1UEChMLSU5FU0MgUG9ydG8xDDAK BgNVBAsTA1VUTTEfMB0GA1UEAxMWSU5FU0MgUG9ydG8gLSBVVE0gLSBDQTEmMCQGCSqGSIb3DQEJ ARYXY2FtYW5hZ2VyQGluZXNjcG9ydG8ucHQCASMwDQYJKoZIhvcNAQEBBQAEgYBvY8O2xmJGXnyB BYO5s5qEeTaHiZuz+RN/WBxMiIKYNW0njz+LwMaV9muMwrBm06rRha0oUdedIbA5rjCz2Btn1qt/ yND8XCXWY2GQl+lRP4ONMX7hLcY/0MQfrh22tDTnbNvUcRUXOyrm/wYQ+rR4mVg9e7l645BzHZbP HmHuvwAAAAAAAA== ------=_NextPart_000_0000_01C759BF.63AEBC90-- --===============1229063628== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram --===============1229063628==-- From ram-bounces@iab.org Mon Feb 26 12:20:13 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjTd-000323-E7; Mon, 26 Feb 2007 12:17:29 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjTc-00031t-Gc for ram@iab.org; Mon, 26 Feb 2007 12:17:28 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjTb-0006mH-BS for ram@iab.org; Mon, 26 Feb 2007 12:17:28 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D6BD4872F3; Mon, 26 Feb 2007 12:17:22 -0500 (EST) To: ram@iab.org Subject: Re: [RAM] candidate properties of some new name types Message-Id: <20070226171722.D6BD4872F3@mercury.lcs.mit.edu> Date: Mon, 26 Feb 2007 12:17:22 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Max Tulyev > The main idea of FQDN-based multihoming I got precisely that far in the message and took a fault. To think of doing anything routing-related with FQDN's is, IMO, a really bad idea. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 12:45:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtd-0008EV-Ds; Mon, 26 Feb 2007 12:44:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtb-0008Dy-SQ for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjtZ-0000lp-BC for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate7.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l1QHiBkf217858 for ; Mon, 26 Feb 2007 17:44:11 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1QHi6VA1318932 for ; Mon, 26 Feb 2007 17:44:11 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1QHi6hb031239 for ; Mon, 26 Feb 2007 17:44:06 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1QHi64C031233; Mon, 26 Feb 2007 17:44:06 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 SAA290582; Mon, 26 Feb 2007 18:44:03 +0100 Message-ID: <45E30BC5.3020000@zurich.ibm.com> Date: Mon, 26 Feb 2007 17:33:09 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Rui Campos Subject: Re: [RAM] candidate properties of some new name types References: <019101c75996$bd200ff0$351975c2@Globo> In-Reply-To: <019101c75996$bd200ff0$351975c2@Globo> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org It's pretty clear that using DNS in this way is a hack. The interactions with DNS TTL misimplementation are pretty likely to break it, and in any case how does it help TCP session survival? I think we need to take the discussion up a level. What's the goal here? If the goal is a dynamic mapping service with certain characteristics, we can then figure out if the DNS can do it, or if we need something new. Brian On 2007-02-26 12:10, Rui Campos wrote: > Hi Max Tulyev, > > See my comments inline. Thanks! > > BR, > Rui Campos > > -----Original Message----- > From: Max Tulyev [mailto:maxtul@netassist.kiev.ua] > Sent: segunda-feira, 26 de Fevereiro de 2007 11:46 > To: ram@iab.org > Subject: Re: [RAM] candidate properties of some new name types > > Hi all, > > The main idea of FQDN-based multihoming is a patched DNS server with TTL > always 1 in replies. FQDN is not a subject of change, but IP to resolve > to is. > [Rui Campos] Are you really considering the scenario I have mentioned in my > e-mail below? I know that the FQDN will not change if a host stays connected > within the same domain. But, what about the scenario where you jump from > domain to domain? This does not seem to be supported by the mechanism you > are talking about, unless I am missing something here ;-) > > The DNS server resolves host to IP not only using name of this host, but > using other information such as IP of requestor,From ram-bounces@iab.org Mon Feb 26 12:45:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtd-0008EV-Ds; Mon, 26 Feb 2007 12:44:21 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtb-0008Dy-SQ for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjtZ-0000lp-BC for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate7.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l1QHiBkf217858 for ; Mon, 26 Feb 2007 17:44:11 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1QHi6VA1318932 for ; Mon, 26 Feb 2007 17:44:11 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1QHi6hb031239 for ; Mon, 26 Feb 2007 17:44:06 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1QHi64C031233; Mon, 26 Feb 2007 17:44:06 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 SAA290582; Mon, 26 Feb 2007 18:44:03 +0100 Message-ID: <45E30BC5.3020000@zurich.ibm.com> Date: Mon, 26 Feb 2007 17:33:09 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Rui Campos Subject: Re: [RAM] candidate properties of some new name types References: <019101c75996$bd200ff0$351975c2@Globo> In-Reply-To: <019101c75996$bd200ff0$351975c2@Globo> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org It's pretty clear that using DNS in this way is a hack. The interactions with DNS TTL misimplementation are pretty likely to break it, and in any case how does it help TCP session survival? I think we need to take the discussion up a level. What's the goal here? If the goal is a dynamic mapping service with certain characteristics, we can then figure out if the DNS can do it, or if we need something new. Brian On 2007-02-26 12:10, Rui Campos wrote: > Hi Max Tulyev, > > See my comments inline. Thanks! > > BR, > Rui Campos > > -----Original Message----- > From: Max Tulyev [mailto:maxtul@netassist.kiev.ua] > Sent: segunda-feira, 26 de Fevereiro de 2007 11:46 > To: ram@iab.org > Subject: Re: [RAM] candidate properties of some new name types > > Hi all, > > The main idea of FQDN-based multihoming is a patched DNS server with TTL > always 1 in replies. FQDN is not a subject of change, but IP to resolve > to is. > [Rui Campos] Are you really considering the scenario I have mentioned in my > e-mail below? I know that the FQDN will not change if a host stays connected > within the same domain. But, what about the scenario where you jump from > domain to domain? This does not seem to be supported by the mechanism you > are talking about, unless I am missing something here ;-) > > The DNS server resolves host to IP not only using name of this host, but > using other information such as IP of requestor, table of really working > interfaces, current load of interfaces and so. > [Rui Campos] Doesn't this mean modification of the world? :-) As far as I > know, today DNS servers do not consider all these parameters for resolving > host to IP. > > Disadvantages of this is all currently active sessions will be dropped > when one of channels will go down, and also DNS replies can not be cached. > > Advantages is we don't need to alter the world to implement it. We can > do it right now. > [Rui Campos] Are you sure you don't need to change the "DNS world" as we > know it today? > > There is many implementations of this schema near me, including for > VoIP. All of them working reasonable for real business. > [Rui Campos] I understand that this can work for local scenarios, as I have > mentioned above. But I doubt it would work in a global scope without > modifying the "DNS world" ;-) > > Rui Campos wrote: >> Hi all, >> >> I have been following the discussions in this list and I just would like > to >> comment this FQDN issue. >> >> IMHO, even if FQDNs are used as identifiers for hosts things will not work > >> properly, at least without modifying the way FQDN assignment works in the >> current Internet (probably that's the your idea, I'm not sure). >> >> Let's consider a host H that attaches itself to different domains along > the >> time. While H is attached to the same domain (e.g., domain1.com.) its FQDN > >> does not change. Then, H can be uniquely identified by a peer host even if > its >> IP address changes, assuming that the mapping FQDN <-> IP address is > handled >> properly. However, when H moves between different domains the FQDN will > change >> at the same pace. For instance, at instant 1 H gets connected to > domain1.com >> and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and > its >> FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to >> domain3 and its FQDN becomes "H.domain3.com". Therefore, every session > bound >> to an FQDN will break when the host moves from one domain to the other. On > the >> other hand, how does a peer host will get informed about the current > host's >> FQDN? >> >> If we consider multi-homed hosts (i.e., hosts with multiple network >> interfaces) the problem is even exacerbated. In fact, multi-homed hosts > may >> have an FQDN per network interface. Then, what FQDN will a peer host use > to >> contact a multi-homed host? There is not a single FQDN that uniquely >> identifies the host regardless of its location and number of network >> interfaces. >> >> BR, >> Rui Campos > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > > > > ------------------------------------------------------------------------ > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 12:45:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtc-0008E3-4I; Mon, 26 Feb 2007 12:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtb-0008Dt-EC for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjtZ-0000lQ-0D for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l1QHiAOj019724 for ; Mon, 26 Feb 2007 17:44:10 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1QHi9qe1581300 for ; Mon, 26 Feb 2007 18:44:09 +0100 Recei table of really working > interfaces, current load of interfaces and so. > [Rui Campos] Doesn't this mean modification of the world? :-) As far as I > know, today DNS servers do not consider all these parameters for resolving > host to IP. > > Disadvantages of this is all currently active sessions will be dropped > when one of channels will go down, and also DNS replies can not be cached. > > Advantages is we don't need to alter the world to implement it. We can > do it right now. > [Rui Campos] Are you sure you don't need to change the "DNS world" as we > know it today? > > There is many implementations of this schema near me, including for > VoIP. All of them working reasonable for real business. > [Rui Campos] I understand that this can work for local scenarios, as I have > mentioned above. But I doubt it would work in a global scope without > modifying the "DNS world" ;-) > > Rui Campos wrote: >> Hi all, >> >> I have been following the discussions in this list and I just would like > to >> comment this FQDN issue. >> >> IMHO, even if FQDNs are used as identifiers for hosts things will not work > >> properly, at least without modifying the way FQDN assignment works in the >> current Internet (probably that's the your idea, I'm not sure). >> >> Let's consider a host H that attaches itself to different domains along > the >> time. While H is attached to the same domain (e.g., domain1.com.) its FQDN > >> does not change. Then, H can be uniquely identified by a peer host even if > its >> IP address changes, assuming that the mapping FQDN <-> IP address is > handled >> properly. However, when H moves between different domains the FQDN will > change >> at the same pace. For instance, at instant 1 H gets connected to > domain1.com >> and its FQDN is "H.domain1.com.", at instant 2 it connects to domain 2 and > its >> FQDN becomes "H.domain2.com." and, finally, at instant 3 it connects to >> domain3 and its FQDN becomes "H.domain3.com". Therefore, every session > bound >> to an FQDN will break when the host moves from one domain to the other. On > the >> other hand, how does a peer host will get informed about the current > host's >> FQDN? >> >> If we consider multi-homed hosts (i.e., hosts with multiple network >> interfaces) the problem is even exacerbated. In fact, multi-homed hosts > may >> have an FQDN per network interface. Then, what FQDN will a peer host use > to >> contact a multi-homed host? There is not a single FQDN that uniquely >> identifies the host regardless of its location and number of network >> interfaces. >> >> BR, >> Rui Campos > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram > > > > ------------------------------------------------------------------------ > > _______________________________________________ > RAM mailing list > RAM@iab.org > https://www1.ietf.org/mailman/listinfo/ram _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 12:45:15 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtc-0008E3-4I; Mon, 26 Feb 2007 12:44:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLjtb-0008Dt-EC for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLjtZ-0000lQ-0D for ram@iab.org; Mon, 26 Feb 2007 12:44:19 -0500 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate3.de.ibm.com (8.13.8/8.13.8) with ESMTP id l1QHiAOj019724 for ; Mon, 26 Feb 2007 17:44:10 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1QHi9qe1581300 for ; Mon, 26 Feb 2007 18:44:09 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1QHi99F004807 for ; Mon, 26 Feb 2007 18:44:09 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1QHi9t4004796; Mon, 26 Feb 2007 18:44:09 +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 SAA145506; Mon, 26 Feb 2007 18:44:07 +0100 Message-ID: <45E30ED3.4030109@zurich.ibm.com> Date: Mon, 26 Feb 2007 17:46:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> <45DF2A62.9080101@crc.u-strasbg.fr> <20293C3B-2D53-4530-8B59-C85F025848E4@cisco.com> In-Reply-To: <20293C3B-2D53-4530-8B59-C85F025848E4@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> In Lisp1, where EID are just ordinary IP addresses, do you assume that >> the ITR > > In all variants of LISP, the EIDs are ordinary IP addresses. Of course, > using this sort of language doesn't really imply that Locators are > extraordinary. Dino, This is why I find your terminology completely confusing. You haven't got an ID/Loc split. You've got two levels of locators (site and global). The cute thing is that your site locators are structured like global locators, and can function as such to some extent. That's great, but if you'd fix your terminology, people would be less confused. See my message sent February 7 for more. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram ved: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1QHi99F004807 for ; Mon, 26 Feb 2007 18:44:09 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1QHi9t4004796; Mon, 26 Feb 2007 18:44:09 +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 SAA145506; Mon, 26 Feb 2007 18:44:07 +0100 Message-ID: <45E30ED3.4030109@zurich.ibm.com> Date: Mon, 26 Feb 2007 17:46:11 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> <45DF2A62.9080101@crc.u-strasbg.fr> <20293C3B-2D53-4530-8B59-C85F025848E4@cisco.com> In-Reply-To: <20293C3B-2D53-4530-8B59-C85F025848E4@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> In Lisp1, where EID are just ordinary IP addresses, do you assume that >> the ITR > > In all variants of LISP, the EIDs are ordinary IP addresses. Of course, > using this sort of language doesn't really imply that Locators are > extraordinary. Dino, This is why I find your terminology completely confusing. You haven't got an ID/Loc split. You've got two levels of locators (site and global). The cute thing is that your site locators are structured like global locators, and can function as such to some extent. That's great, but if you'd fix your terminology, people would be less confused. See my message sent February 7 for more. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 14:06:16 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLl8g-0000pS-N5; Mon, 26 Feb 2007 14:03:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLl8f-0000os-At for ram@iab.org; Mon, 26 Feb 2007 14:03:57 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLl8e-0005a1-1d for ram@iab.org; Mon, 26 Feb 2007 14:03:57 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 26 Feb 2007 11:03:51 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="42721180:sNHT2248913457" 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 l1QJ3pp4004545; Mon, 26 Feb 2007 11:03:51 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QJ3nnZ026418; Mon, 26 Feb 2007 11:03:51 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 11:03:49 -0800 Received: from [192.168.0.4] ([10.21.98.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 11:03:49 -0800 In-Reply-To: <45E30ED3.4030109@zurich.ibm.com> References: <6C2C84E5-23D8-4B88-B43F-F83911BE529B@cs.ucla.edu> <8EF9CA42-28BA-49E7-BA8C-01229145E76C@CS.UCLA.EDU> <467EC9D7-B100-4777-B9F1-AF9ED0FA310E@cisco.com> <45DF2A62.9080101@crc.u-strasbg.fr> <20293C3B-2D53-4530-8B59-C85F025848E4@cisco.com> <45E30ED3.4030109@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: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 26 Feb 2007 11:03:52 -0800 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 19:03:49.0423 (UTC) FILETIME=[D924E3F0:01C759D8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=610; t=1172516631; x=1173380631; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=wz8QVl1UlDPkGzQvvSSk3GPF92sZYAVbH0XSojNNfno=; b=YgglUVU3+rGxfp5poSlmFYfum07cCDWK1vaLSXX6i1A1Uf82bBg099N6z+1yJMf0rVhn9NfK pDfAxHeLiyWOFQTfpzGHlmvMtlh6EBAipb9BI/c1x228vTbvdliVgcuQ; Authentication-Results: sj-dkim-6; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > This is why I find your terminology completely confusing. You haven't We have to go this way to maintain compatibility of existing deployment. > got an ID/Loc split. You've got two levels of locators (site and > global). Right, and the site addresses are used as EIDs by the hosts for transport connection IDs. > The cute thing is that your site locators are structured like global > locators, and can function as such to some extent. That's great, but > if you'd fix your terminology, people would be less confused. > See my message sent February 7 for more. Okay, will do. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 14:58:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlzA-00055G-Ku; Mon, 26 Feb 2007 14:58:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLlz9-00055B-8k for ram@iab.org; Mon, 26 Feb 2007 14:58:11 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLlz5-0004lv-PA for ram@iab.org; Mon, 26 Feb 2007 14:58:11 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l1QJw5c9016455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2007 11:58:05 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l1QJw5eZ026910; Mon, 26 Feb 2007 11:58:05 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l1QJvwWU026598; Mon, 26 Feb 2007 11:58:02 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 11:57:59 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 26 Feb 2007 11:57:28 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040490CF@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdZ2RXpO8q2G+BjR7Wk3buQpqgNUgABe6Ug From: "Henderson, Thomas R" To: "Dino Farinacci" , "Brian E Carpenter" X-OriginalArrivalTime: 26 Feb 2007 19:57:59.0817 (UTC) FILETIME=[6A87A790:01C759E0] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Monday, February 26, 2007 11:04 AM > To: Brian E Carpenter > Cc: ram@iab.org > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > > This is why I find your terminology completely confusing.=20 > You haven't >=20 > We have to go this way to maintain compatibility of existing=20 > deployment. I agree with Brian's complaint here; LISP is really about multiple levels of locators and not really an ID/locator split, based on traditional use of these terms. >=20 > > got an ID/Loc split. You've got two levels of locators (site and =20 > > global). >=20 > Right, and the site addresses are used as EIDs by the hosts for =20 > transport connection IDs. and they are used also as locators by the hosts; hence they are not really split from the host perspective. =20 Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 15:38:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmba-0007Xg-6O; Mon, 26 Feb 2007 15:37:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmbZ-0007WL-5B for ram@ietf.org; Mon, 26 Feb 2007 15:37:53 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmbY-0003n0-3K for ram@ietf.org; Mon, 26 Feb 2007 15:37:53 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1QKbht4018534 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 26 Feb 2007 21:37:44 +0100 (CET) (envelope-from iljitsch@muada.com) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ram@ietf.org From: Iljitsch van Beijnum Date: Mon, 26 Feb 2007 21:37:47 +0100 X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.4 (--) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Subject: [RAM] Can we forget LISP, please? X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org It looks to me that lisp is nothing more than tunneling packets across the DFZ where there is a central mapping database that's distributed through ICMP messages. Please, this has to stop. Three years ago, 40% of the internet melted because routers couldn't keep up with filling their forwarding caches from a LOCALLY AVAILABLE mapping database when a worm hit that made hosts send out 15000 packets per second with random destination addresses. Caching anywhere else but the source host is a non-starter. ICMP is also completely useless because anyone can fake those. What we need is a design that: 1. Aligns cost with benefit = must be done in provider networks, at least at first 2. Enforces renumberability = the locator must be invisible to the end-user 3. Supports the necessary parallelism that allows scaling to arbitrary numbers 4. Doesn't depend on a particular type of traffic, i.e., a million packets to one address works just as well as a million packets to a million different addresses 5. Is less vulnerable to threats than current BGP 6. Supports rerouting after failures = a single global mapping database isn't enough The way I see it, this means that we must come up with a protocol that floods mapping state throughout the network but in a way that allows N devices to each hold 1/N part of the full global state and process 1/N of the global updates. This protocol needs good security and quick reaction to outages, which are things that current BGP doesn't do adequately. But since there are no users yet, we get to do a greenfield design so it should be doable. The details of the encapsulation are completely uninteresting at this stage. I would even go so far as to say that we shouldn't mandate any, but rather, allow vendors to implement different ones as required and supported by the hardware available. We should also steer clear of philosophizing about the nature of names. We currently have IP addresses. We can't even renumber those or move from one version to another within a reasonable timeframe, so IP addresses as they are today are a given. Anything that happens below IP is very interesting to those that it concerns, but not to the architecture of the internet at large since layers below IP have no global significance. So, let the vendors or some sub-IP group figure this out, it doesn't matter in the grand scheme of things. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 15:46:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmjO-0003ls-Vk; Mon, 26 Feb 2007 15:45:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmjO-0003lm-9W for ram@ietf.org; Mon, 26 Feb 2007 15:45:58 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmjN-0005BA-0m for ram@ietf.org; Mon, 26 Feb 2007 15:45:58 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 26 Feb 2007 12:45:56 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="393795038:sNHT89643996" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1QKjuvx000865 for ; Mon, 26 Feb 2007 12:45:56 -0800 Received: from [124.81.250.38] (sjc-vpn7-343.cisco.com [10.21.145.87]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1QKjtnF022210 for ; Mon, 26 Feb 2007 12:45:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Can we forget LISP, please? Date: Mon, 26 Feb 2007 12:45:32 -0800 To: ram@ietf.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=895; t=1172522756; x=1173386756; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=rdobbins@cisco.com; z=From:=20Roland=20Dobbins=20 |Subject:=20Re=3A=20[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=g/+xi8Nkkzvz0DhyBCA5tn+mggrG/io4GsknauCRHDw=; b=jcp0pDzWu1JncaizibdrUUkgT473dA1RwCdE268LaXqkbrWgjJ81wqeghUQgxFQJJLr1kjgS BnuUxM8o0Xc4pxHXuIlKGcvPC7Q2N/ec7pOPYMj/4jigz3ls4gNy2f8i; Authentication-Results: sj-dkim-8; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Feb 26, 2007, at 12:37 PM, Iljitsch van Beijnum wrote: > since layers below IP have no global significance. So, let the > vendors or some sub-IP group figure this out, it doesn't matter in > the grand scheme of things. I have to disagree with this statement - yes, that's how things work - today-, but it's not necessarily how they -have- to work tomorrow. Now, it may well be that whatever approaches we believe are valid keep this current separation, but I wouldn't suggest taking it off the table out of hand, until some sort of consensus on some of the grosser points of the desired architecture/paradigm is achieved. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice The telephone demands complete participation. -- Marshall McLuhan _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 16:56:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnnK-00076F-DM; Mon, 26 Feb 2007 16:54:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLmpF-000806-Ft for ram@ietf.org; Mon, 26 Feb 2007 15:52:01 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLmot-0006L6-F3 for ram@ietf.org; Mon, 26 Feb 2007 15:52:01 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 064C7872CD; Mon, 26 Feb 2007 15:51:38 -0500 (EST) To: ram@ietf.org Subject: Re: [RAM] Can we forget LISP, please? Message-Id: <20070226205138.064C7872CD@mercury.lcs.mit.edu> Date: Mon, 26 Feb 2007 15:51:38 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: Iljitsch van Beijnum > The details of the encapsulation are completely uninteresting ... > I would even go so far as to say that we shouldn't mandate any, but > rather, allow vendors to implement different ones as required and > supported by the hardware available. The rest of your message I want to ponder at more length, but this part I think I can take issue with now. The problem with letting vendors roll their own proprietary wrappings is that then you lose interoperability, the ability to build a system out of components from multiple vendors. That's been one of the biggest strengths of the I* stack all along - the fact that all the standards are open, and common, so that multi-vendor interoperability was a given. Let's not throw this away without a good reason - and I don't see a good reason gere. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 17:02:14 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnuw-0002Xt-5N; Mon, 26 Feb 2007 17:01:58 -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 Cc: Lixia Zhang Subject: [RAM] IRTF RRG: call for participation X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 17:03:51 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnwk-00049x-OE; Mon, 26 Feb 2007 17:03:50 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnwT-00045S-5i for ram@iab.org; Mon, 26 Feb 2007 17:03:33 -0500 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLnw6-0006EP-Ot for ram@iab.org; Mon, 26 Feb 2007 17:03:33 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 26 Feb 2007 14:03:10 -0800 X-IronPort-AV: i="4.14,221,1170662400"; d="scan'208"; a="764577960:sNHT44230020" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l1QM3ASS015700; Mon, 26 Feb 2007 14:03:10 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l1QM2sGw026473; Mon, 26 Feb 2007 14:03:10 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:03:06 -0800 Received: from [192.168.0.4] ([10.21.98.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 14:03:06 -0800 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040490CF@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D040490CF@XCH-NW-5V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 26 Feb 2007 14:03:09 -0800 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 26 Feb 2007 22:03:06.0439 (UTC) FILETIME=[E4D34570:01C759F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=215; t=1172527390; x=1173391390; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=tHrw1f6f2A0oMA6BMOVWFKAUgobCTVUiK1RCIKI+rIM=; b=a/T0WyzIaI8E9hrfipZl7Ha3eVaZ8ymn5KYUZcNqIvurAgvQ8FJ1q4QVzSTRgnGFh2Tg6sei aHuWB/yA8+BKWf7AaoC9VwWHE2vLwy9ugyxgkfz7tcJ/waxuMRjlj29LYAWYWNPeV9VgdlVMxL f8UNPSJcMuhlZPRHwnmAcw39g=; Authentication-Results: sj-dkim-1; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > I agree with Brian's complaint here; LISP is really about multiple > levels of locators and not really an ID/locator split, based on > traditional use of these terms. LISP is both, just like GSE is. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 17:29:40 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLoLO-00013b-VD; Mon, 26 Feb 2007 17:29:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLnou-0007ry-0F for ram@ietf.org; Mon, 26 Feb 2007 16:55:44 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLniL-0005XT-LW for ram@ietf.org; Mon, 26 Feb 2007 16:49:06 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1QLmnAf020196 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 26 Feb 2007 22:48:49 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <20070226205138.064C7872CD@mercury.lcs.mit.edu> References: <20070226205138.064C7872CD@mercury.lcs.mit.edu> 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: Iljitsch van Beijnum Subject: Re: [RAM] Can we forget LISP, please? Date: Mon, 26 Feb 2007 22:48:51 +0100 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 26-feb-2007, at 21:51, Noel Chiappa wrote: > The problem with letting vendors roll their own proprietary > wrappings is > that then you lose interoperability, the ability to build a system > out of > components from multiple vendors. That's been one of the biggest > strengths > of the I* stack all along - the fact that all the standards are > open, and > common, so that multi-vendor interoperability was a given. You're right, of course. Although this is a detail and we can have many different encapsulations, and maybe there is not even a need to define one as a lowest common denominator, it's still good to have interoperability. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 18:30:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpGp-0000NF-Ra; Mon, 26 Feb 2007 18:28:40 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLpFp-0008HJ-9y for ram@iab.org; Mon, 26 Feb 2007 18:27:37 -0500 Received: from blv-smtpout-01.boeing.com ([130.76.32.69] helo=blv-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLpFl-0003zI-WD for ram@iab.org; Mon, 26 Feb 2007 18:27:37 -0500 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l1QNRUbt025806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 26 Feb 2007 15:27:30 -0800 (PST) Received: from blv-av-01.boeing.com (localhost [127.0.0.1]) by blv-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l1QNRUfC012315; Mon, 26 Feb 2007 15:27:30 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by blv-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l1QNRUHK012304; Mon, 26 Feb 2007 15:27:30 -0800 (PST) Received: from XCH-NW-5V1.nw.nos.boeing.com ([130.247.55.44]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 15:27:30 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Mon, 26 Feb 2007 15:26:48 -0800 Message-ID: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Architectural comments on draft-farinacci-lisp-00 Thread-Index: AcdZ8egzk1Dk7cDTTGa4MZd2iqTb2gACWdIg From: "Henderson, Thomas R" To: "Dino Farinacci" X-OriginalArrivalTime: 26 Feb 2007 23:27:30.0160 (UTC) FILETIME=[AF09C700:01C759FD] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org =20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Monday, February 26, 2007 2:03 PM > To: Henderson, Thomas R > Cc: Brian E Carpenter; ram@iab.org > Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 >=20 > > I agree with Brian's complaint here; LISP is really about multiple > > levels of locators and not really an ID/locator split, based on > > traditional use of these terms. >=20 > LISP is both, just like GSE is. >=20 It's not equivalent to GSE, which actually split the IP address into ID and locator portions. LISP is an ID/locator separation (the draft title uses the word separation, but also uses the word "split" internally) only in the context of a particular address allocation and routing policy. Again, this is just terminology, but I think it would be more precise to define it in terms of multiple locator spaces that are tunneled over one another, for purposes of core routing scalability. Tom _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Feb 26 19:44:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqQ8-0000IU-NV; Mon, 26 Feb 2007 19:42:20 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLqOU-0007HE-8l for ram@iab.org; Mon, 26 Feb 2007 19:40:38 -0500 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLqOK-0007NA-DX for ram@iab.org; Mon, 26 Feb 2007 19:40:38 -0500 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id F0272872FF; Mon, 26 Feb 2007 19:40:27 -0500 (EST) To: ram@iab.org Subject: RE: [RAM] Architectural comments on draft-farinacci-lisp-00 Message-Id: <20070227004027.F0272872FF@mercury.lcs.mit.edu> Date: Mon, 26 Feb 2007 19:40:27 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Cc: jnc@mercury.lcs.mit.edu X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > From: "Henderson, Thomas R" > LISP is an ID/locator separation .. only in the context of a > particular address allocation and routing policy. > ... > .. it would be more precise to define it in terms of multiple locator > spaces that are tunneled over one another, for purposes of core > routing scalability. This analysis doesn't seen sound to me. Here's my take on the situation. To begin with, it's important to recognize that LISP - especially in its early deployment stages - is just not going to provide clean *anthing*, simply because of the "change engines while the airplane is in flight" situation - and in particular, its desire (for good reasons) to want to be deployable without benefit of host hanges (e.g. HIP or GSE). So, to get a clearer picture of what LISP is actually doing, you need to look further down the deployment path (e.g. to when the LISP functionality is pushed down to the first-hop routers). To turn to a more architectural analysis, the LISP EID's are "locators" (some claim) which are i) globally unique (modulo NAT issues, let's put that off for a moment), ii) indicate where the named entity is - in the sense of having topology information embedded *in the name* - only within a *very* limited scope. Moreover, to find out where, in a *larger* (global) scope, the named entity is, you *have* to map the EID into a different kind of name, one which *does* have more topological information embedded within the name. So here's my question: if I have a "locator" which globally, uniquely identifies something, but which includes topological location information in the name for only a limited scope, what happens in the limiting case, where that scope is reduced to the the named entity itself? In what sense is that "locator" a locator any more? Now put that observation together with my first point, and when you do that, here's what you see: as the LISP mapping functionality is pushed closer and closer to the hosts (e.g. into the first-hop routers), the EID's of LISP start acting more and more like real EID's. So I think their terminology is a reasonable attempt to deal with an ugly, complex and confusing reality. Hopefully, if things unroll the way the LISP proponents plan for, over time things will clear up some. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 02:53:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLx7P-0000qW-No; Tue, 27 Feb 2007 02:51:27 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLx7N-0000o0-Tg for ram@ietf.org; Tue, 27 Feb 2007 02:51:25 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLx7M-0004oU-Ar for ram@ietf.org; Tue, 27 Feb 2007 02:51:25 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-2.cisco.com with ESMTP; 26 Feb 2007 23:51:22 -0800 X-IronPort-AV: i="4.14,223,1170662400"; d="scan'208"; a="363079925:sNHT56980344" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1R7pMPO027681; Mon, 26 Feb 2007 23:51:22 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1R7pIho011671; Mon, 26 Feb 2007 23:51:18 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 23:51:18 -0800 Received: from [192.168.0.4] ([10.21.98.42]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Feb 2007 23:51:17 -0800 In-Reply-To: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Can we forget LISP, please? Date: Mon, 26 Feb 2007 23:51:21 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Feb 2007 07:51:17.0800 (UTC) FILETIME=[101D9A80:01C75A44] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5819; t=1172562682; x=1173426682; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=mQFDquTQgxqNuv2sjFSdY0GspYx/NMOQDiNPNUFWAz0=; b=Jhu6ScOh6nx5yo27Tc3TrJli7EMoRTS3ONGslZavazsGHoKs9xPzCt5i5MTriL82n9r+iwxy Y9ZgT+NMtiwqj+WEocpL93OK+laClxHaNEkQhekJkoCgQABsMoPDaJ67; Authentication-Results: sj-dkim-7; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.4 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > It looks to me that lisp is nothing more than tunneling packets > across the Yes, and that could be a feature and not a bug. The solution is not revolutionary, it is trying to incrementally get deployed for *both* IPv4 and IPv6. To make that statement requires some hard design decisions to be made. Ones that many people won't agree with. But for one thing, we are listening to the operators, because he they say no way off the bat, then the proposal isn't going anywhere. > DFZ where there is a central mapping database that's distributed > through The database of Locators is not centralized. The locators are IP addresses of the various ETRs at destination sites. > ICMP messages. Please, this has to stop. Three years ago, 40% of > the internet melted because routers couldn't keep up with filling > their forwarding caches from a LOCALLY AVAILABLE mapping database > when a worm hit that made hosts send out 15000 packets per second > with random There are lots of reasons why things didn't work in the past. Would you rather pass around all the EID-RLOC mappings around with a protocol and have everyone store every possible destination they might ever want to talk to? You have to make this look something like DNS caching for the same scalability reasons. > destination addresses. Caching anywhere else but the source host is > a non-starter. ICMP is also completely useless because anyone can > fake those. Anyone can redirect my packets today as well. We will authenticate the ICMP packets but that won't be the end-all to security. We made the choices we did with LISP because we are listening to the operators. And you heard them to at the IAB workshop. I assumed you were listening carefully. They need something trivially to deploy and they want it quickly. If you want a full fledge solution, then go look at shim6, you know how long that is taking to get deployed. They have said, their multi-homed customers want to control ingress traffic. They have said, they themselves want more control of doing traffic engineering without polluting the rest of the Internet with more specifics. They have said, less routes and stress to the system helps the entire routing system and the products they use. > What we need is a design that: > > 1. Aligns cost with benefit = must be done in provider networks, at > least at first Yes, but the problem on this list is that different people have different cost thresholds and want different levels of benefit. > 2. Enforces renumberability = the locator must be invisible to the > end-user It doesn't have to be invisible, it can serve your purpose by being opaque as well. GSE, in the host treats the RG as opaque, LISP, in the host doesn't even know about the inter-domain locator (so it is invisible). > 3. Supports the necessary parallelism that allows scaling to > arbitrary numbers Right, this is a motherhood and apple pie statement. > 4. Doesn't depend on a particular type of traffic, i.e., a million > packets to one address works just as well as a million packets to a > million different addresses Right, and your point? > 5. Is less vulnerable to threats than current BGP The -01 draft of LISP will have some security mechanisms in place. But don't expect much or the operators won't deploy it. > 6. Supports rerouting after failures = a single global mapping > database isn't enough The -00 draft talks about Locator reachability. There is a conservative solution written down. > The way I see it, this means that we must come up with a protocol > that floods mapping state throughout the network but in a way that > allows N devices to each hold 1/N part of the full global state and > process 1/N of The solution space will vary depending on how much mapping state there will be. > the global updates. This protocol needs good security and quick > reaction to outages, which are things that current BGP doesn't do > adequately. But since there are no users yet, we get to do a > greenfield design so it should be doable. I think there are some ideas from Compact Routing that we can use. If we can use a tunnel topology, with some strict hierarchy that doesn't have to change, we can keep the table size down for EID mappings to n**2 for 2**n EIDs. If we use a tunnel topology and have some richness of connectivity underneath it (which I think we have in the Internet), there won't be reason for tunnel topology changes, so the lookup for a mapping won't have to be distributed, you can follow an independent-named tree to get you the answer you want to your EID lookup. This will scale much better. And I think it could even be static. For IPv6, you can have the entire EID space come out of a single TLA prefix but for IPv4, you may need a collection of class As. But what if IANA could allocate 32.0.0.0/3 for EID assignments for the entire Internet! That would give us a half of a billion that could be assigned to only the hosts that needed global connectivity. Just a thought. I know a knee-jerk reaction is to do this in BGP, but if the EID- prefix space is too granular, we'll see the EID database just as large as the Locator database, and we don't need it to be that large. > The details of the encapsulation are completely uninteresting at > this stage. I would even go so far as to say that we shouldn't > mandate any, but rather, allow vendors to implement different ones > as required and supported by the hardware available. This is certainly a detail that we shouldn't screw up but there are bigger fish to fry at the moment. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 03:01:39 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxGw-0003gn-0O; Tue, 27 Feb 2007 03:01:18 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxGu-0003ge-HN for ram@iab.org; Tue, 27 Feb 2007 03:01:16 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxGt-0006H6-71 for ram@iab.org; Tue, 27 Feb 2007 03:01:16 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-6.cisco.com with ESMTP; 27 Feb 2007 00:01:14 -0800 X-IronPort-AV: i="4.14,223,1170662400"; d="scan'208"; a="116417820:sNHT52127496" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1R81EVD011428; Tue, 27 Feb 2007 00:01:14 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1R81Dho015813; Tue, 27 Feb 2007 00:01:14 -0800 (PST) Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 00:01:13 -0800 Received: from [192.168.0.4] ([10.21.98.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 00:01:13 -0800 In-Reply-To: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> References: <77F357662F8BFA4CA7074B0410171B6D040490D2@XCH-NW-5V1.nw.nos.boeing.com> 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: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 27 Feb 2007 00:01:17 -0800 To: "Henderson, Thomas R" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Feb 2007 08:01:13.0354 (UTC) FILETIME=[7317EEA0:01C75A45] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1823; t=1172563274; x=1173427274; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=W7aFDzVTUVSOhwNLWJXMCHieWtwoxxf3pxGhkA8LkPU=; b=vN6JrxoLyBDLBRuMtF7BMWKRcIUFtMHWlgF7LAQGdLSBT0ViZg8Flc9Ogu+2GSP3ySYK4QfG vLtg+RKvHX430feu36y2OcW9S+1VWnBXO9hOtB/5uc6ia3wR7vpFY0/W; Authentication-Results: sj-dkim-5; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> I agree with Brian's complaint here; LISP is really about multiple >>> levels of locators and not really an ID/locator split, based on >>> traditional use of these terms. >> >> LISP is both, just like GSE is. >> > > It's not equivalent to GSE, which actually split the IP address > into ID > and locator portions. LISP is an ID/locator separation (the draft > title Yes, GSE "splits" using a contiguous set of bits. LISP "separates" using two addresses in different parts of the packet. > uses the word separation, but also uses the word "split" internally) > only in the context of a particular address allocation and routing > policy. Again, this is just terminology, but I think it would be more > precise to define it in terms of multiple locator spaces that are > tunneled over one another, for purposes of core routing scalability. The problem I have with the purest point of view is that we can't get it incrementally deployed if we do that. In LISP, the IP address in DNS is used as a connection-id for socket API calls and since we don't want to change the host, the host stack has to emit packets with this destination address. Having this address be a locator for a local scope varies on how wide your scope is. If your ITRs are on link with the host, the IP address emitted by the host really doesn't locate anything but is used as a key to find a Locator value. Furthermore, if you change this, you can't do local routing within the site. We don't want to force enterprises to renumber their subnets or reconfigure their routing protocols just to solve the "global problem". If it isn't going to buy them anything, they aren't going to change a thing. So we are not even going to attempt a design that requests them to do so. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 03:13:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxRt-0005V8-Uc; Tue, 27 Feb 2007 03:12:37 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxRs-0005V0-Ux for ram@iab.org; Tue, 27 Feb 2007 03:12:36 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxRr-0007WL-HU for ram@iab.org; Tue, 27 Feb 2007 03:12:36 -0500 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 27 Feb 2007 00:12:25 -0800 X-IronPort-AV: i="4.14,223,1170662400"; d="scan'208"; a="42960618:sNHT46653219" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l1R8CPJp017459; Tue, 27 Feb 2007 00:12:25 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1R8CNho021730; Tue, 27 Feb 2007 00:12:23 -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); Tue, 27 Feb 2007 00:12:22 -0800 Received: from [192.168.0.4] ([10.21.98.42]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 00:12:22 -0800 In-Reply-To: <20070227004027.F0272872FF@mercury.lcs.mit.edu> References: <20070227004027.F0272872FF@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6A39A3B3-ADAB-4161-AE7D-CFB5F8C25A1D@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Architectural comments on draft-farinacci-lisp-00 Date: Tue, 27 Feb 2007 00:12:26 -0800 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 27 Feb 2007 08:12:22.0370 (UTC) FILETIME=[01DBAC20:01C75A47] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2185; t=1172563945; x=1173427945; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Architectural=20comments=20on=20draft-farinac ci-lisp-00 |Sender:=20; bh=m5HQ1b10vlehP2C0jKcvm06xJsr7hmBfCpcBYplxcAQ=; b=bmk5m59Z3UrL4U31sa7gvbUUjlaPhEFybImaHfR7BSIKSuBs13fKUXjNdnyvcu7nzF7GhAik 6CqcJi676nynJ2jMJgRxPTTJ72R4T2N5QOl0oDelr5rOpO61WiLpvMlV; Authentication-Results: sj-dkim-8; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org > To turn to a more architectural analysis, the LISP EID's are > "locators" > (some claim) which are i) globally unique (modulo NAT issues, let's > put > that off for a moment), ii) indicate where the named entity is - in > the > sense of having topology information embedded *in the name* - only > within a > *very* limited scope. Moreover, to find out where, in a *larger* > (global) > scope, the named entity is, you *have* to map the EID into a > different kind > of name, one which *does* have more topological information > embedded within > the name. Well said. > So here's my question: if I have a "locator" which globally, uniquely > identifies something, but which includes topological location > information > in the name for only a limited scope, what happens in the limiting > case, > where that scope is reduced to the the named entity itself? In what > sense > is that "locator" a locator any more? Interesting comment. I guess the outer headers will always be Locators and when packets reach the egress tunnel routers and the header gets stripped they are no longer useful. So in this case, these "outer addresses" are always just Locators. But the inner header has the limited scope Locator-then-just-ID as you state above. > Now put that observation together with my first point, and when you do > that, here's what you see: as the LISP mapping functionality is pushed > closer and closer to the hosts (e.g. into the first-hop routers), > the EID's > of LISP start acting more and more like real EID's. Yes, in this case they are used as a key to get a MAC address to physically forward to the last-hop system. But I would argue in this case they are used as keys for the ARP cache where when they are egressing a site, they are used as keys for the Locator lookup. > So I think their terminology is a reasonable attempt to deal with > an ugly, > complex and confusing reality. Hopefully, if things unroll the way > the LISP > proponents plan for, over time things will clear up some. And there probably will be more "devil in the details" as we proceed. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 03:37:31 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxpH-0005Qy-5y; Tue, 27 Feb 2007 03:36:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLxpF-0005Qk-7C for ram@ietf.org; Tue, 27 Feb 2007 03:36:45 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLxpD-0001FH-SH for ram@ietf.org; Tue, 27 Feb 2007 03:36:45 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 519B8212D47; Tue, 27 Feb 2007 10:36:40 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id D9241212D37; Tue, 27 Feb 2007 10:36:39 +0200 (EET) In-Reply-To: <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68F47693-36E2-483A-8B07-C00C3FFC6BA9@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Can we forget LISP, please? Date: Tue, 27 Feb 2007 10:36:37 +0200 To: Dino Farinacci , Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Firstly, as I have stated earlier, and tried to outline in the generix draft, I think we can do basically what LISP tried to do by proxying SHIM6 or HIP. That should lead to roughly equal deployment speed. The system might not be as "simple" as what LISP appears to be, but not necessarily that complex either. Secondly, what I've heard from multiple sources is that people don't agree on the necessity of getting this out "quickly". Yes, there is a looming problem, but people seem to disagree how many years we have time still. Apparently at least a couple of years, though. So, my take on this is that we shouldn't just forget LISP. IMHO, there are a few good ideas there. However, I still believe that we should aim for a more "proper" ID/loc split than what LISP at its current state can provide. IMHO, that would bring forth multiple benefits in the form of really upgrading the architecture in the slightly longer run, such as proper support for all kinds middle boxes (and not just TRs), ability to better integrated IPv4 and IPv6 (something which HIP provides today), optimised support for mobile routers, combined support for host mobility and multi-homing (HIP does that) and site multi-homing and TE (an open issue, see Elwyn Davie's very good mail on the arch-d list), etc. We should not commit ourselves to any single proposal at this time. Instead, we should try to understand the strengths and drawbacks of the different proposals, aiming for something more comprehensive (but of course not try to boil the oceans). It would be a mistake to focus only on the routing table problem. Given the current looming crisis, we have a great opportunity to finally upgrade the architecture by adding a proper new name space, something that Saltzer called for already in 1982. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 05:23:48 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzSe-00048C-HJ; Tue, 27 Feb 2007 05:21:32 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzSe-000487-3Y for ram@ietf.org; Tue, 27 Feb 2007 05:21:32 -0500 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzSc-0005hg-NK for ram@ietf.org; Tue, 27 Feb 2007 05:21:32 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l1RALK4n050616 for ; Tue, 27 Feb 2007 10:21:20 GMT Received: from d06av01.portsmouth.uk.ibm.com (d06av01.portsmouth.uk.ibm.com [9.149.37.212]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1RALJsL856154 for ; Tue, 27 Feb 2007 10:21:19 GMT Received: from d06av01.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1RALJqx024434 for ; Tue, 27 Feb 2007 10:21:19 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av01.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1RALJAD024425; Tue, 27 Feb 2007 10:21:19 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 LAA303524; Tue, 27 Feb 2007 11:21:18 +0100 Message-ID: <45E4061E.2030600@zurich.ibm.com> Date: Tue, 27 Feb 2007 11:21:18 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Pekka Nikander Subject: Re: [RAM] Can we forget LISP, please? References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <68F47693-36E2-483A-8B07-C00C3FFC6BA9@nomadiclab.com> In-Reply-To: <68F47693-36E2-483A-8B07-C00C3FFC6BA9@nomadiclab.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 2007-02-27 09:36, Pekka Nikander wrote: > Firstly, as I have stated earlier, and tried to outline in the generix > draft, I think we can do basically what LISP tried to do by proxying > SHIM6 or HIP. I can't speak for HIP, but from early work I've seen on proxying SHIM6, I'm quite concerned that moving this function out of the host will recreate some of the evils of NAT (deep packet inspection, transport checksum munging, and potentially ALGs). The neat thing that host SHIM6 and LISP have in common is that they avoid this, by unambiguously preserving e2e identifiers. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 05:42:19 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzmG-000854-68; Tue, 27 Feb 2007 05:41:48 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzmE-00084s-IG for ram@ietf.org; Tue, 27 Feb 2007 05:41:46 -0500 Received: from smtp-3.dynsipr.ucl.ac.be ([130.104.4.3] helo=smtp3.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzm8-00009f-9N for ram@ietf.org; Tue, 27 Feb 2007 05:41:46 -0500 Received: from smtp3.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP id 408CF13F8D; Tue, 27 Feb 2007 11:41:35 +0100 (CET) Received: from [192.168.10.10] (unknown [130.104.70.132]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 27 Feb 2007 11:41:31 +0100 (CET) Message-ID: <45E40ADA.8030804@info.ucl.ac.be> Date: Tue, 27 Feb 2007 11:41:30 +0100 From: Olivier Bonaventure User-Agent: Mozilla Thunderbird 1.0.8-1.1.fc4 (X11/20060501) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Iljitsch van Beijnum Subject: Re: [RAM] Can we forget LISP, please? References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> In-Reply-To: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> X-Enigmail-Version: 0.93.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: n'est pas un polluriel, SpamAssassin (not cached, score=-22.185, requis 5, autolearn=not spam, BAYES_00 -2.60, RCVD_AUTH_OK -20.00, SARE_FROM_SPAM_WORD3 0.10, SARE_MILLIONSOF 0.32, SPF_HELO_PASS -0.00) X-SGSI-From: bonaventure@info.ucl.ac.be X-SGSI-Spam-Status: No X-Spam-Score: 0.4 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Bonaventure@info.ucl.ac.be List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Iljitsch, > It looks to me that lisp is nothing more than tunneling packets across > the DFZ where there is a central mapping database that's distributed > through ICMP messages. Please, this has to stop. I disagree, LISP has the potential of bringing additional benefits and is worth being considered. > Three years ago, 40% > of the internet melted because routers couldn't keep up with filling > their forwarding caches from a LOCALLY AVAILABLE mapping database when > a worm hit that made hosts send out 15000 packets per second with > random destination addresses. We should not based architectural decisions for the future internet on implementation problems in the past internet. > Caching anywhere else but the source host > is a non-starter. ICMP is also completely useless because anyone can > fake those. ICMP looks to me like an interim solution, let's consider also lisp 1.5, LISP2, ... > What we need is a design that: > > 1. Aligns cost with benefit = must be done in provider networks, at > least at first LISP-like solutions could also provide benefits for the customer networks. For example LISP can allow a stub AS to control its incoming and outgoing traffic, which can be a strong incentive for stub ASes to request from their providers the deployment of LISP-like solutions. > 2. Enforces renumberability = the locator must be invisible to the > end-user > 3. Supports the necessary parallelism that allows scaling to arbitrary > numbers > 4. Doesn't depend on a particular type of traffic, i.e., a million > packets to one address works just as well as a million packets to a > million different addresses The type of traffic to support will be an engineering decision. For me, it would seem reasonable to optimise a platform to better support a million packets sent to one address than a million packets to a million different addresses, especially at the edge. At the edge, there are few real applications needing to send packets to millions of destinations. > 5. Is less vulnerable to threats than current BGP > 6. Supports rerouting after failures = a single global mapping database > isn't enough The rerouting after failure is orthogonal for me. To achieve fast recovery after failures, local solutions are better than global solutions because they react faster and do not require a full routing convergence. In fact, tunnels can also be used to provide fast failover of BGP peering links in case of failures, see: http://www.info.ucl.ac.be/people/OBO/papers/f41-bonaventure.pdf > The way I see it, this means that we must come up with a protocol that > floods mapping state throughout the network but in a way that allows N > devices to each hold 1/N part of the full global state and process 1/N > of the global updates. You basically propose to use a DHT to distribute the mapping, this is one of the possible implementations of the mapping. > This protocol needs good security and quick > reaction to outages, which are things that current BGP doesn't do > adequately. But since there are no users yet, we get to do a greenfield > design so it should be doable. I think that greenfield design could be an objective for version 2. Olivier -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/~obo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 05:53:11 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzwh-00051y-K8; Tue, 27 Feb 2007 05:52:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzwg-0004zh-NV for ram@ietf.org; Tue, 27 Feb 2007 05:52:34 -0500 Received: from n2.nomadiclab.com ([193.234.219.2]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzwf-0001m0-Ap for ram@ietf.org; Tue, 27 Feb 2007 05:52:34 -0500 Received: from n2.nomadiclab.com (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id BC949212D49; Tue, 27 Feb 2007 12:52:29 +0200 (EET) Received: from [127.0.0.1] (localhost [127.0.0.1]) by n2.nomadiclab.com (Postfix) with ESMTP id 50C83212D48; Tue, 27 Feb 2007 12:52:29 +0200 (EET) In-Reply-To: <45E4061E.2030600@zurich.ibm.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <68F47693-36E2-483A-8B07-C00C3FFC6BA9@nomadiclab.com> <45E4061E.2030600@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: <0662ED87-EF44-4BB0-9C01-3BEC65A9288E@nomadiclab.com> Content-Transfer-Encoding: 7bit From: Pekka Nikander Subject: Re: [RAM] Can we forget LISP, please? Date: Tue, 27 Feb 2007 12:52:27 +0200 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> Firstly, as I have stated earlier, and tried to outline in the >> generix draft, I think we can do basically what LISP tried to do >> by proxying SHIM6 or HIP. > > I can't speak for HIP, but from early work I've seen on proxying > SHIM6, > I'm quite concerned that moving this function out of the host will > recreate some of the evils of NAT (deep packet inspection, transport > checksum munging, and potentially ALGs). The neat thing that host > SHIM6 > and LISP have in common is that they avoid this, by unambiguously > preserving e2e identifiers. Hmm. Apparently I haven't seen the work(s) you are referring to, but my immediate reaction is to suspect deployment scenarios. If you attempt to proxy full SHIM6 functionality without carefully planning the network structure and numbering, I can imagine such things to be needed. However, if you dedicate one of your prefixes as the only prefix the legacy hosts know, the only bigger problem I see is co- ordination between parallel SHIM6 proxies sitting at different site borders. And that shouldn't be so hard to solve, either. For early deployment, we should probably aim for even smaller subset of functionality, perhaps not even supporting multi-homing for legacy hosts. Of course, that would foil the very SHIM6 goal for those hosts, but OTOH as far as I can see it might provide benefits similar to what LISP is designed to provide. --Pekka Nikander _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 05:53:38 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzxe-00010P-JK; Tue, 27 Feb 2007 05:53:34 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HLzxb-0000fq-Ru for ram@ietf.org; Tue, 27 Feb 2007 05:53:31 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HLzxZ-0001s2-AQ for ram@ietf.org; Tue, 27 Feb 2007 05:53:31 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id A3A1C53E1B5; Tue, 27 Feb 2007 05:53:26 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id Uxlwoq7KiiBy; Tue, 27 Feb 2007 05:53:18 -0500 (EST) Received: from [124.81.250.36] (unknown [124.81.250.34]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 0AF4D53E072; Tue, 27 Feb 2007 05:53:15 -0500 (EST) In-Reply-To: <45E40ADA.8030804@info.ucl.ac.be> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <45E40ADA.8030804@info.ucl.ac.be> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <90AD69DE-D7E5-48BC-89D3-3772ABBD6E08@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] Can we forget LISP, please? Date: Tue, 27 Feb 2007 18:53:11 +0800 To: Bonaventure@info.ucl.ac.be X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Feb 27, 2007, at 6:41 PM, Olivier Bonaventure wrote: > We should not based architectural decisions for the future internet on > implementation problems in the past internet. No but we might want to keep in mind architectural problems of the past Internet. Knowing the difference between an architectural problem and a mere implementation foible is non-trivial in some cases, but the sorry history of cache-based routers from multiple different vendors is at least suggestive. "Those who cannot remember the past are condemned to repeat it." -- Santayana --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 06:16:23 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM0J3-00084C-Pn; Tue, 27 Feb 2007 06:15:41 -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 Subject: RE: [RAM] IRTF RRG: call for participation 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 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 06:44:36 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM0jS-00020q-2T; Tue, 27 Feb 2007 06:42:58 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM0jO-0001uq-38 for ram@ietf.org; Tue, 27 Feb 2007 06:42:54 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM0jN-00018k-C1 for ram@ietf.org; Tue, 27 Feb 2007 06:42:54 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1RBgavl036903 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 27 Feb 2007 12:42:36 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Can we forget LISP, please? Date: Tue, 27 Feb 2007 12:42:39 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.4 (--) X-Scan-Signature: 926f893f9bbbfa169f045f85f0cdb955 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 27-feb-2007, at 8:51, Dino Farinacci wrote: > To make that statement requires some hard design decisions to be > made. Ones that many people won't agree with. Ah, but how do you know that people disagree because the idea is bad or disagree because they have it wrong? > But for one thing, we are listening to the operators, because he > they say no way off the bat, then the proposal isn't going anywhere. I don't think we should only consider ideas that have operator support out of the gate. It's the end result that counts. >> DFZ where there is a central mapping database that's distributed >> through > The database of Locators is not centralized. The locators are IP > addresses of the various ETRs at destination sites. Ok, centralized is probably not the right word. The difference that I was trying to get at is the one between a (distributed) database where the information is the same from every vantage point, i.e., the DNS or something like it, or a distributed database where the information is processed as it flows through the system so certain attributes are different depending on where they are observed. Routing protocols work like this, the next hop address and path are different everywhere. If we go for a DNS-like system, it's necessary to enrich the static information with reachability information. This is what the REAP protocol in shim6 does. Protocols like this don't lend themselves very well to being implemented in the middle rather than at the endpoints, like with shim6. >> Three years ago, 40% of the internet melted because routers >> couldn't keep up with filling their forwarding caches from a >> LOCALLY AVAILABLE mapping database when a worm hit that made hosts >> send out 15000 packets per second with random > There are lots of reasons why things didn't work in the past. I don't see how things are different now. > Would you rather pass around all the EID-RLOC mappings around with > a protocol and have everyone store every possible destination they > might ever want to talk to? Yes. This has the advantage that it doesn't introduce delays, different behavior for different traffic mixes or non-determinism. > You have to make this look something like DNS caching for the same > scalability reasons. A DNS-like approach only works as long as you're talking to a relatively small subset of all possible destinations. I contend that this isn't true for most routers in large ISP networks. Maybe they don't see packets to 200k different prefixes every hour or every 5 minutes, but I'm pretty sure it's still a fairly big fraction of all possible destinations, such as 50k or so. At these levels, the extra overhead of managing the caching defeats the advantage of not having to hold a full table, especially on DRAM based systems, because the issue with DRAM isn't the cost per size, but the access speed. But maybe we can split the difference and build a design where there are two tiers of mapping devices (or clusters of mapping devices): ones that hold the full state, and ones that don't. Then the decision about whether to deploy a single tier 1 mapping device, a cluster of devices that holds the full mapping state or a tier 2 caching mapping device is up to individual operators. > Anyone can redirect my packets today as well. We will authenticate > the ICMP packets but that won't be the end-all to security. The current interdomain routing security situation isn't exactly the best possible one. Authenticating (ICMP) messages from unknown sources is a hard thing to do. > We made the choices we did with LISP because we are listening to > the operators. And you heard them to at the IAB workshop. I assumed > you were listening carefully. What I keep hearing is "make the problem go away without us having to change any of our current practices"... > They need something trivially to deploy and they want it quickly. > If you want a full fledge solution, then go look at shim6, you know > how long that is taking to get deployed. The internet isn't going to melt down tomorrow or next week. The IETF is fundamentally incapable of producing short term results, anyway. So if we can't have it really fast (as opposed to "IETF fast") we should make sure that at least, it's good. I don't know how long it takes for shim6 to be deployed, because it's not finished yet. I do know that it takes forever to develop it. There are many reasons for this, and an important one that doesn't apply here is that only few people are willing to put in the time and even fewer to put in the amounts of time that make it progress quickly. But that doesn't apply here. If we can agree on an approach, split off the different parts so that different groups can work on the parts concurrently, we should have something ready for review this year and all the details hammered out and some early implementations next year. > They have said, their multi-homed customers want to control ingress > traffic. They have said, they themselves want more control of doing > traffic engineering without polluting the rest of the Internet with > more specifics. They have said, less routes and stress to the > system helps the entire routing system and the products they use. All of this sounds good to me. >> 1. Aligns cost with benefit = must be done in provider networks, >> at least at first > Yes, but the problem on this list is that different people have > different cost thresholds and want different levels of benefit. Economics is very simple: you buy a new box only if it either makes you money or saves you money. For end-users, new boxes don't make or save money. For ISPs they can if they're looking at six figures per new router with the old ones keeling over. Obviously this means that there must be incremental benefits with incremental deployment. >> 2. Enforces renumberability = the locator must be invisible to the >> end-user > It doesn't have to be invisible, it can serve your purpose by being > opaque as well. GSE, in the host treats the RG as opaque, LISP, in > the host doesn't even know about the inter-domain locator (so it is > invisible). I'll use "invisible" for short here. It's not inconceivable that the locator is visible to the end-user with renumberability intact, but this requires a *very* strong argument. All previous renumbering efforts never went anywhere. >> 3. Supports the necessary parallelism that allows scaling to >> arbitrary numbers > Right, this is a motherhood and apple pie statement. I take that to mean "something everyone agrees is good". That's not what I mean. The issue with current routing is that all information and a lot of packets come together in the same place. This requires lots of speed, power and money. The only way to get around that is make sure not all information has to come together for all of this to work. (In theory we could also reduce the amount of traffic in these hot spots, but traffic will continue to increase so even if we're successful that means effectively treading water, which doesn't help us enough to be useful.) >> 4. Doesn't depend on a particular type of traffic, i.e., a million >> packets to one address works just as well as a million packets to >> a million different addresses > Right, and your point? Caching only works with a limited number of flows. Since there is no inherent limit on the number of flows, we can't depend on caching to save us. > I think there are some ideas from Compact Routing that we can use. > If we can use a tunnel topology, with some strict hierarchy that > doesn't have to change, we can keep the table size down for EID > mappings to n**2 for 2**n EIDs. Hierarchical tunneling? Why not simply have hierarchical routing then? Tunneling is just a mechanism to reduce the number of places where routing decisions have to be made. If we can do a hierarchy, then it's probably a good tradeoff to route in a few more places and ditch the tunnels. > For IPv6, you can have the entire EID space come out of a single > TLA prefix but for IPv4, you may need a collection of class As. But > what if IANA could allocate 32.0.0.0/3 for EID assignments for the > entire Internet! That would give us a half of a billion that could > be assigned to only the hosts that needed global connectivity. I don't like having separate ID and LOC address spaces. I doubt whether this will buy us anything useful, and I prefer having a knob that I can turn from "every ID is a LOC" like we have now to "complete separation" but also to settings somewhere in between as required and desired. For this, IDs must remain able to function as LOCs like they can today. > I know a knee-jerk reaction is to do this in BGP What I'd like to see is a new protocol that has some similarities to BGP, but rather than facilitate hop-by-hop forwarding by distributing next hop information, it distributes "last hop" information so that packets can be tunneled to a decapsulation box at or just before the destination. I don't want to look at real routing at this layer, but I do want to be able to dynamically switch from one tunnel to another as required by changes in reachability or TE. >> The details of the encapsulation are completely uninteresting at >> this stage. I would even go so far as to say that we shouldn't >> mandate any, but rather, allow vendors to implement different ones >> as required and supported by the hardware available. > This is certainly a detail that we shouldn't screw up but there are > bigger fish to fry at the moment. Exactly. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 11:15:00 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM4y2-0003e2-8y; Tue, 27 Feb 2007 11:14:18 -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 Subject: Re: [RAM] IRTF RRG: call for participation 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 X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.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 >> _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 13:21:56 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6uo-0007ct-2h; Tue, 27 Feb 2007 13:19:06 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HM6um-0007c8-Fj for ram@ietf.org; Tue, 27 Feb 2007 13:19:04 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HM6uj-0008OQ-3i for ram@ietf.org; Tue, 27 Feb 2007 13:19:04 -0500 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 27 Feb 2007 10:19:02 -0800 X-IronPort-AV: i="4.14,226,1170662400"; d="scan'208"; a="394308682:sNHT48885252" 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 l1RIJ0ke004301; Tue, 27 Feb 2007 10:19:00 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l1RIIrnF023896; Tue, 27 Feb 2007 10:18:53 -0800 (PST) Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Feb 2007 10:18:52 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Can we forget LISP, please? Date: Tue, 27 Feb 2007 10:18:51 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> In-Reply-To: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdZ5iH9+Ynqr3BBQ/+3jgqlGQuLqAAsryQg References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> From: "Darrel Lewis \(darlewis\)" To: "Iljitsch van Beijnum" , X-OriginalArrivalTime: 27 Feb 2007 18:18:52.0871 (UTC) FILETIME=[BC497570:01C75A9B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2655; t=1172600340; x=1173464340; c=relaxed/simple; s=sjdkim6002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20\(darlewis\)=22=20 |Subject:=20RE=3A=20[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=vbcQmeagk6TEHANGBHWasRyPAckabF2WzhhieaZDnSc=; b=O97CjchADdSyZl3Ijf3BfgpNsR0MemJ7R3AYd9MVCXq1npT/ck6TmtQCwJWpTOXVYoO4ca5R vJ0zaTsOtv1UyppOe09LteabUPCk1lSVvb+Uz3rJVMZc7EVWIJ2tyudw; Authentication-Results: sj-dkim-6; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I'll leave most of this to others to comment on, however I feel that there are a few points below that should be discussed further. =20 Iljitsch van Beijnum wrote: > It looks to me that lisp is nothing more than tunneling > packets across the DFZ where there is a central mapping > database that's distributed through ICMP messages. Please, > this has to stop. Three years ago, 40% of the internet melted > because routers couldn't keep up with filling their > forwarding caches from a LOCALLY AVAILABLE mapping database > when a worm hit that made hosts send out 15000 packets per > second with random destination addresses. Caching anywhere > else but the source host is a non-starter. ICMP is also > completely useless because anyone can fake those. >=20 I see two (main) fundamental security challenges to be addressed with LISP. =20 The first, as you mention above, is the ability to 'fake' ICMP request packets. It is important to note that ICMP isn't the problem, LISP could have picked a new IP protocol number and packet, used UDP, or any number of things, but the problem would remain. When a new mapping request packet arrives at the ETR, the ETR cannot just process this packet without some way to validate that this packet came from the source in the source address field. Rate limiting these packets is not a solution due to the inability to classify good from bad by just looking at the initial packet. There are two ways to solve this problem today* (maybe more...?), one is a multi-packet exchange that uses nonce values and return routability to verify the source. TCP syn-cookies is an example of this type of approach. The second is some sort of proof of identity using symmetrical keying. Both of these approaches can be implemented in the dataplane, which will be a requirement to avoid the DoS. The second major challenge that I see in LISP is the case where a source spoofs the ID of a third party and sends a packet from a reachable/valid locator. The ETR needs a mechanism to validate the ITR/Locator mapping. (Today this is done with return routability, which makes it very difficult to fake establishment of TCP connections without being a MITM attack, or L2 spoofing). Some sort of cert based ID/Loc mapping database needs to exist for the ETR to be able to use to verify that the source ID/Loc is valid. There may be many other security issues out there, but if we can solve these two and not break LISP, IMHO we'll have a good foundation to work on. -D *Dave Oran gets credit for his succinct summary of this issue in an email a couple of months ago. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 22:08:33 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMF8k-0005It-5u; 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: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Feb 27 23:36:49 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMGVf-0008E3-81; 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: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.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 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 02:51:55 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJZS-00050v-Ra; Wed, 28 Feb 2007 02:49:54 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMJZS-00050o-41 for ram@ietf.org; Wed, 28 Feb 2007 02:49:54 -0500 Received: from smtp.nokia.com ([131.228.20.173] helo=mgw-ext14.nokia.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMJZQ-0000ag-3k for ram@ietf.org; Wed, 28 Feb 2007 02:49:54 -0500 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext14.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l1S7jOpQ017275; Wed, 28 Feb 2007 09:45:48 +0200 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 09:49:46 +0200 Received: from esebe101.NOE.Nokia.com ([172.21.138.215]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 09:49:46 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Can we forget LISP, please? Date: Wed, 28 Feb 2007 09:49:44 +0200 Message-ID: In-Reply-To: <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdZ5iH9+Ynqr3BBQ/+3jgqlGQuLqAAsryQgABxv0mA= References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> From: To: , , X-OriginalArrivalTime: 28 Feb 2007 07:49:46.0133 (UTC) FILETIME=[03E41450:01C75B0D] X-Nokia-AV: Clean X-Spam-Score: 0.2 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Darrel Lewis wrote: >I see two (main) fundamental security challenges to be=20 >addressed with LISP. =20 > >The first, as you mention above, is the ability to 'fake' ICMP=20 >request packets. It is important to note that ICMP isn't the=20 ... > >There are two ways to solve this problem today* (maybe=20 >more...?), one is a multi-packet exchange that uses nonce=20 >values and return routability to verify the source. TCP=20 >syn-cookies is an example of this type of approach. The=20 >second is some sort of proof of identity using symmetrical=20 >keying. Both of these approaches can be implemented in the=20 >dataplane, which will be a requirement to avoid the DoS. > Aren't you dismissing an obvious third solution, i.e. the use of cryptographically bound identities as IDs? It seems to me that LISP would work rather well with CGAs as in SHIM6? In the ultimate deployment on first hop routers the CGAs would not even need to be routable at all. Also, I would argue that rather increasingly large domains can be made economically feasible with routing on flat labels, like in rbridges (~ campus wide routing on flat MAC addresses). >The second major challenge that I see in LISP is the case=20 >where a source spoofs the ID of a third party and sends a=20 >packet from a reachable/valid locator. The ETR needs a=20 >mechanism to validate the ITR/Locator mapping. This is trivial with CGAs. >(Today this is done with return routability, which makes it=20 >very difficult to fake establishment of TCP connections=20 >without being a MITM attack, or L2 spoofing). Some sort of=20 >cert based ID/Loc mapping database needs to exist for the ETR=20 >to be able to use to verify that the source ID/Loc is valid. > All of this is unnecessary with CGAs. Indeed this is the major benefit of them :-) >There may be many other security issues out there, but if we=20 >can solve these two and not break LISP, IMHO we'll have a good=20 >foundation to work on. > We have a solid foundation in understanding CGAs from the work of the past 8 or so years. I see no reason why they would not be usable also with LISP. There are two issues, however: 1. CGAs work only with IPv6. Depending on your viewpoint this may not be a problem at all. Indeed deploying IPv6 in LISP-style would help scaling the DFZ routing, as there would be no need to have IPv6 locator routes in the RIB in the DFZ. 2. Current practice allows only for ~64 crypto-bits in a CGA. It would be better to carve out a portion of the IPv6 address space for e.g. /28 prefixes (for EID resolution aggregation) and ~100 bits for crypto. Would be more secure and future proof. Regards, Jarno _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 06:47:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNEE-0007p6-BT; Wed, 28 Feb 2007 06:44:14 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNED-0007oj-5j for ram@iab.org; Wed, 28 Feb 2007 06:44:13 -0500 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMNEB-0006qj-LS for ram@iab.org; Wed, 28 Feb 2007 06:44:13 -0500 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id B4319A63B2 for ; Wed, 28 Feb 2007 12:44:10 +0100 (CET) Received: from [163.117.139.88] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.88]) by smtp03.uc3m.es (Postfix) with ESMTP id 9D329A78FE for ; Wed, 28 Feb 2007 12:44:10 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v624) Content-Transfer-Encoding: 7bit Message-Id: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: marcelo bagnulo braun Date: Wed, 28 Feb 2007 12:45:50 +0100 X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 Subject: [RAM] Fwd: I-D ACTION:draft-bagnulo-pshim6-00.txt X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi, i have included in this draft some level of detail on how to do proxies in shim6, in order to support unmodified hosts, allow some middle boxes to perform egress path selection and provide PI identifiers, so that we can have an idea of how this would look like in the shim approach Comments are welcome Regards, marcelo Inicio mensaje reenviado: > De: Internet-Drafts@ietf.org > Fecha: 27 de febrero de 2007 21:50:02 GMT+01:00 > Para: i-d-announce@ietf.org > Cc: Asunto: I-D ACTION:draft-bagnulo-pshim6-00.txt > Responder a: internet-drafts@ietf.org > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > > Title : Proxy Shim6 (P-Shim6) > Author(s) : M. Bagnulo > Filename : draft-bagnulo-pshim6-00.txt > Pages : 22 > Date : 2007-2-27 > > This draft discusses extensions to the shim6 architecture to support > shim6 proxies that would allow the provision of the following > capabilities: > o Provide Upper Layer Identifier portability. > o Provide Traffic Engineering policy enforcement. > o Off-load of the shim6 context management from the actual peers of > the communication. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-bagnulo-pshim6-00.txt > > To remove yourself from the I-D Announcement list, send a message to > i-d-announce-request@ietf.org with the word unsubscribe in the body of > the message. > You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce > to change your subscription settings. > > Internet-Drafts are also available by anonymous FTP. Login with the > username "anonymous" and a password of your e-mail address. After > logging in, type "cd internet-drafts" and then > "get draft-bagnulo-pshim6-00.txt". > > A list of Internet-Drafts directories can be found in > http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > Internet-Drafts can also be obtained by e-mail. > > Send a message to: > mailserv@ietf.org. > In the body type: > "FILE /internet-drafts/draft-bagnulo-pshim6-00.txt". > > NOTE: The mail server at ietf.org can return the document in > MIME-encoded form by using the "mpack" utility. To use this > feature, insert the command "ENCODING mime" before the "FILE" > command. To decode the response(s), you will need "munpack" or > a MIME-compliant mail reader. Different MIME-compliant mail readers > exhibit different behavior, especially when dealing with > "multipart" MIME messages (i.e. documents which have been split > up into multiple messages), so check your local documentation on > how to manipulate these messages. > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > Content-Type: text/plain > Content-ID: <2007-2-27120849.I-D@ietf.org> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 07:26:57 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNsR-0002KL-Kj; Wed, 28 Feb 2007 07:25:47 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMNsQ-0002KG-UR for ram@iab.org; Wed, 28 Feb 2007 07:25:46 -0500 Received: from stl-smtpout-01.boeing.com ([130.76.96.56] helo=stl-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMNsN-00047u-LA for ram@iab.org; Wed, 28 Feb 2007 07:25:46 -0500 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l1SCPe6J016457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 28 Feb 2007 06:25:41 -0600 (CST) Received: from slb-av-01.boeing.com (localhost [127.0.0.1]) by slb-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l1SCPehN006569 for ; Wed, 28 Feb 2007 04:25:40 -0800 (PST) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by slb-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l1SCPda5006554 for ; Wed, 28 Feb 2007 04:25:40 -0800 (PST) Received: from XCH-NW-7V2.nw.nos.boeing.com ([130.247.54.35]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 04:25:39 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 28 Feb 2007 04:25:39 -0800 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177475F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IP with Virtual Link eXtension (IPvLX) Thread-Index: AcdbLiJl/lCgsjmjRraEgzAQ++OXMgAAwZSA References: <27784b8985021d6bac8639dd59e0973c@it.uc3m.es> From: "Templin, Fred L" To: X-OriginalArrivalTime: 28 Feb 2007 12:25:39.0595 (UTC) FILETIME=[8E85EDB0:01C75B33] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [RAM] IP with Virtual Link eXtension (IPvLX) X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I haven't had time to follow these discussions closely, but anyone interested in the proposals being discussed here might also be interested in IP with Virtual Link eXtension (IPvLX): http://www.ietf.org/internet-drafts/draft-templin-ipvlx-06.txt Not making any claims of originality, but the proposal has been around for several years and is about joining sites that can use provider-independent addressing across a global Internet routing core that uses provider-aggregated addressing. PI-to-PA mappings are not conveyed in routing protocols; they are kept in the global DNS instead. In its current manifestation, the proposal assumes IPv6 sites with an IPv4 Internet routing core, but there is no reason it couldn't be extended to support any IPv*/IPv* combination. I would be interested to hear what people think about this. Fred fred.l.templin@boeing.com =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 13:14:28 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTIR-0007cz-Vs; Wed, 28 Feb 2007 13:13:00 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMTIQ-0007cs-UQ for ram@ietf.org; Wed, 28 Feb 2007 13:12:58 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMTIO-00019R-Jx for ram@ietf.org; Wed, 28 Feb 2007 13:12:58 -0500 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2007 10:12:56 -0800 X-IronPort-AV: i="4.14,231,1170662400"; d="scan'208"; a="43709612:sNHT101626137" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l1SICuHf011112; Wed, 28 Feb 2007 10:12:56 -0800 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1SICki0003609; Wed, 28 Feb 2007 10:12:50 -0800 (PST) Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 10:12:48 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [RAM] Can we forget LISP, please? Date: Wed, 28 Feb 2007 10:12:47 -0800 Message-ID: <60C4A248E730F249990993E3B9BD44D80322B688@xmb-sjc-218.amer.cisco.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Can we forget LISP, please? Thread-Index: AcdZ5iH9+Ynqr3BBQ/+3jgqlGQuLqAAsryQgABxv0mAAFla3IA== References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> From: "Darrel Lewis \(darlewis\)" To: , , X-OriginalArrivalTime: 28 Feb 2007 18:12:48.0176 (UTC) FILETIME=[0D532B00:01C75B64] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=871; t=1172686376; x=1173550376; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=darlewis@cisco.com; z=From:=20=22Darrel=20Lewis=20\(darlewis\)=22=20 |Subject:=20RE=3A=20[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=iUMZrDchg3JDnnqopJcoZeYXhsPvdwrE2CAWpev6Fnk=; b=oRpU0e+6zu5kmXah0yN2Kk/75IiFZOPM71/6dk3g1rEYF4Sld1pi/ONjYoub6SQzvBkdPK5U +Qsax6G9wx+3uIiAElRo969reC3/Ef9WwE1BCpkZpft533GaMaotXytI; Authentication-Results: sj-dkim-5; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org jarno.rajahalme@nokia.com wrote: > There are two issues, however: >=20 > 1. CGAs work only with IPv6. Depending on your viewpoint this may not=20 > be a problem at all. Indeed deploying IPv6 in LISP-style would help=20 > scaling the DFZ routing, as there would be no need to have IPv6=20 > locator routes in the RIB in the DFZ. >=20 It was my (unstated) viewpoint that LISP should work with IPv4 - so I admit that I was not thinking in terms of a v6 only solution. It definitely does change your viewpoint to limit the problem space to v6! I definitely think you have a point with regards to doing source verification via CGA mechanisms in LISP. I think further thought should go into exploring the points that you've raised about its benefits for authenticating the source of Request packets as well as the mapping of EID/Loc values. -D _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 16:14:50 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMW6f-0003S9-K9; Wed, 28 Feb 2007 16:13:01 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMW6d-0003RV-Nl for ram@ietf.org; Wed, 28 Feb 2007 16:12:59 -0500 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HMW6Z-0003y0-Lt for ram@ietf.org; Wed, 28 Feb 2007 16:12:59 -0500 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 28 Feb 2007 13:12:20 -0800 X-IronPort-AV: i="4.14,232,1170662400"; d="scan'208"; a="394999699:sNHT87252181240" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-7.cisco.com (8.12.11/8.12.11) with ESMTP id l1SLCJEX009321; Wed, 28 Feb 2007 13:12:19 -0800 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l1SLC8i4007542; Wed, 28 Feb 2007 13:12:15 -0800 (PST) Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 13:12:08 -0800 Received: from [192.168.0.4] ([10.21.80.218]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 13:12:08 -0800 In-Reply-To: <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> 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: Dino Farinacci Subject: Re: [RAM] Can we forget LISP, please? Date: Wed, 28 Feb 2007 13:12:11 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 28 Feb 2007 21:12:08.0293 (UTC) FILETIME=[1ADAB950:01C75B7D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6541; t=1172697139; x=1173561139; c=relaxed/simple; s=sjdkim7002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=t9fOxu8qAJoVqUSpNbRkpAD35aDmF0iT9I1BLKoWwSM=; b=dO4+2hRizIh7bjBFpGTdlrmOzF0NrFJi+EMdC5V94eUOD9ZxodFjC0oq0dVRgzJzhlloeMic xlCUG3SO5uTCpIPxiV6i3sBY8+YzfCWa591Fgr2GjVbTJlNhmuLmmv5w; Authentication-Results: sj-dkim-7; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim7002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >> But for one thing, we are listening to the operators, because he >> they say no way off the bat, then the proposal isn't going anywhere. > > I don't think we should only consider ideas that have operator > support out of the gate. It's the end result that counts. Are you joking or is this a serious statement? There will be no end result without their buy-in. >> Would you rather pass around all the EID-RLOC mappings around with >> a protocol and have everyone store every possible destination they >> might ever want to talk to? > > Yes. This has the advantage that it doesn't introduce delays, > different behavior for different traffic mixes or non-determinism. Tradeoffs. >> You have to make this look something like DNS caching for the same >> scalability reasons. > > A DNS-like approach only works as long as you're talking to a > relatively small subset of all possible destinations. For the reason you don't put ITRs (for prepending the locator header) in the ISP network. You put it at the source site. >> Anyone can redirect my packets today as well. We will authenticate >> the ICMP packets but that won't be the end-all to security. > > The current interdomain routing security situation isn't exactly > the best possible one. Authenticating (ICMP) messages from unknown > sources is a hard thing to do. Yes, you are right. >> We made the choices we did with LISP because we are listening to >> the operators. And you heard them to at the IAB workshop. I >> assumed you were listening carefully. > > What I keep hearing is "make the problem go away without us having > to change any of our current practices"... Well, yes, that would be the path of least resistance for them. Of course, they know you never get a free lunch so it's a negotiating dance to see what changes more, practices or the solution space. They really want things to work. It's in their best interest. >> They need something trivially to deploy and they want it quickly. >> If you want a full fledge solution, then go look at shim6, you >> know how long that is taking to get deployed. > > The internet isn't going to melt down tomorrow or next week. The > IETF is fundamentally Right, but we have to start development now so we are ready when it does. This opportunity is taking a proactive rather than reactive approach. If we wait to reactive we will be rushed to do the right solution. > If we can agree on an approach, split off the different parts so > that different groups can The collective "we" will never agree. So this can't be a prerequisite for going to the next step. > work on the parts concurrently, we should have something ready for > review this year and all the details hammered out and some early > implementations next year. I think this is actually happening. I personally am interested in playing with GSE to see how a different approach can be used but still router-based with no host changes. GSE could be just as easy to deploy as LISP but serves IPv6 only. I was wondering if anything thinks GSE could work for IPv4. Comments? It will limit the number of connections a host can make globally but I want to throw it out and see what folks think? >> Right, and your point? > > Caching only works with a limited number of flows. Since there is > no inherent limit on the number of flows, we can't depend on > caching to save us. Hmm. The BGP RIB is a sort of a cache. Anyways, the EID database can and must be highly aggregatable and since EID mappings won't change like ISP-connection-changes and links and nodes going up an down, there will not be entropy in the EID-prefix space. So I think the EID cache could be considerably smaller and certainly so in many places. >> I think there are some ideas from Compact Routing that we can use. >> If we can use a tunnel topology, with some strict hierarchy that >> doesn't have to change, we can keep the table size down for EID >> mappings to n**2 for 2**n EIDs. > > Hierarchical tunneling? Yes, increasing stretch for bootstrapping a EID-to-RLOC mapping may be tolerable since it's just a lookup that is following this topology and not the real data flow. So a stretch of 3 for this control-plane operation is quite acceptable. At least in my mind. > Why not simply have hierarchical routing then? You can and we do, but there are too many backdoors at the edges of the network the way the Internet is today. The "EID-lookup-topology" doesn't need to have these backdoors IMO. > Tunneling is just a mechanism to reduce the number of places where > routing decisions have to be made. If we can do a hierarchy, then > it's probably a good tradeoff to route in a few more places and > ditch the tunnels. Right. >> For IPv6, you can have the entire EID space come out of a single >> TLA prefix but for IPv4, you may need a collection of class As. >> But what if IANA could allocate 32.0.0.0/3 for EID assignments for >> the entire Internet! That would give us a half of a billion that >> could be assigned to only the hosts that needed global connectivity. > > I don't like having separate ID and LOC address spaces. I doubt > whether this will buy us anything useful, and I prefer having a > knob that I can turn from "every ID is a LOC" like we have now to > "complete separation" but also to settings somewhere in between as > required and desired. For this, IDs must remain able to function as > LOCs like they can today. I think you just described LISP and didn't realize it. >> I know a knee-jerk reaction is to do this in BGP > > What I'd like to see is a new protocol that has some similarities > to BGP, but rather than facilitate hop-by-hop forwarding by > distributing next hop information, it distributes "last hop" > information so that packets can be tunneled to a decapsulation box > at or just before the destination. I don't want to look at real > routing at this layer, but I do want to be able to dynamically > switch from one tunnel to another as required by changes in > reachability or TE. Understand. >> This is certainly a detail that we shouldn't screw up but there >> are bigger fish to fry at the moment. > > Exactly. Then why did you bring up an issue about encapsulation. It detracted from your other more important points. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 16:58:24 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWnq-0003Bv-FW; Wed, 28 Feb 2007 16:57:38 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWnp-0003A4-C8 for ram@ietf.org; Wed, 28 Feb 2007 16:57:37 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMWno-0005FW-BA for ram@ietf.org; Wed, 28 Feb 2007 16:57:37 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1SLvFtD067932 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Feb 2007 22:57:16 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <82C79563-790E-4E8C-8EE8-074429B42B5E@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Can we forget LISP, please? Date: Wed, 28 Feb 2007 22:57:07 +0100 To: Dino Farinacci X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 28-feb-2007, at 22:12, Dino Farinacci wrote: >>> But for one thing, we are listening to the operators, because he >>> they say no way off the bat, then the proposal isn't going anywhere. >> I don't think we should only consider ideas that have operator >> support out of the gate. It's the end result that counts. > Are you joking or is this a serious statement? There will be no end > result without their buy-in. What I mean is that obviously, the finished solution should have operator support. But since most operators aren't protocol designers, I don't necessarily trust them as a group to be able to judge a solution before it's finished. >> A DNS-like approach only works as long as you're talking to a >> relatively small subset of all possible destinations. > For the reason you don't put ITRs (for prepending the locator > header) in the ISP network. You put it at the source site. Then how do you get end-users to deploy those boxes? We haven't exactly been successful in getting them to turn IPv6 on even though they got it for free with the hardware they bought for IPv4. (At least, a good number of them did.) The ISPs benefit, this means the ISPs must be the ones that make the decision whether to deploy the mechanism. People who don't benefit don't deploy. >>> They need something trivially to deploy and they want it quickly. >>> If you want a full fledge solution, then go look at shim6, you >>> know how long that is taking to get deployed. >> The internet isn't going to melt down tomorrow or next week. > Right, but we have to start development now so we are ready when it > does. This opportunity is taking a proactive rather than reactive > approach. If we wait to reactive we will be rushed to do the right > solution. Agree. And we shouldn't be _too_ ambitious or we won't get anything done. But if we aren't ambitious enough, we'll only succeed in creating something that doesn't really solve much. >> If we can agree on an approach, split off the different parts so >> that different groups can > The collective "we" will never agree. So this can't be a > prerequisite for going to the next step. :-) Well we agreed more than I would have expected in october, so why not see if we can agree some more? > I personally am interested in playing with GSE to see how a > different approach can be used but still router-based with no host > changes. GSE could be just as easy to deploy as LISP but serves > IPv6 only. Would be nice if someone could fill in the missing pieces to make GSE a complete solution, though... > I was wondering if anything thinks GSE could work for IPv4. > Comments? It will limit the number of connections a host can make > globally but I want to throw it out and see what folks think? GSE splits the address into two parts, hard to do with only 32 or even 48 (NAT...) bits. You can of course always find more address bits by adding extra tunnel headers, which also helps with keeping the whole thing more backward compatible. This could actually work, but then we're back at how to find outer tunnel addresses (LOCs) to go along with inner tunnel addresses (IDs). So that brings us back to the core of what we were discussing already. >> Caching only works with a limited number of flows. Since there is >> no inherent limit on the number of flows, we can't depend on >> caching to save us. > Hmm. The BGP RIB is a sort of a cache. Anyways, the EID database > can and must be highly aggregatable and since EID mappings won't > change like ISP-connection-changes and links and nodes going up an > down, there will not be entropy in the EID-prefix space. > So I think the EID cache could be considerably smaller and > certainly so in many places. Aggregation is no magic bullet. What this gives you is the ability to have a bunch of routers that handle 0/1 and another bunch of routers that handle 128/1 so that each set only needs to know about half the internet = the required parallelism. But you still need to have the full global information in the aggregate set of routers, so you're still dealing with large dynamic tables, the difference is that when the tables get _too_ large you can add boxes. >> I don't like having separate ID and LOC address spaces. I doubt >> whether this will buy us anything useful, and I prefer having a >> knob that I can turn from "every ID is a LOC" like we have now to >> "complete separation" but also to settings somewhere in between as >> required and desired. For this, IDs must remain able to function >> as LOCs like they can today. > I think you just described LISP and didn't realize it. Could be, the draft isn't the easiest one to decipher... I'm not saying there is nothing useful in LISP, what I'm saying is that it attacks the problem from the wrong end: it's the mapping distribution that's the core of the problem, if we figure that out everything else will fall into place. >>> This is certainly a detail that we shouldn't screw up but there >>> are bigger fish to fry at the moment. >> Exactly. > Then why did you bring up an issue about encapsulation. It > detracted from your other more important points. It seemed like the right thing to say at the time. :-) Iljitsch _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 17:01:10 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWrG-0003Fp-IA; Wed, 28 Feb 2007 17:01:10 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMWrE-00038b-Ql for ram@ietf.org; Wed, 28 Feb 2007 17:01:08 -0500 Received: from [2001:1af8:2:5::2] (helo=sequoia.muada.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMWrE-0005vu-By for ram@ietf.org; Wed, 28 Feb 2007 17:01:08 -0500 Received: from [IPv6:2001:1af8:6::20a:95ff:fef5:246e] (alumange.muada.com [IPv6:2001:1af8:6:0:20a:95ff:fef5:246e]) (authenticated bits=0) by sequoia.muada.com (8.13.3/8.13.3) with ESMTP id l1SM0w3I068026 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 28 Feb 2007 23:00:58 +0100 (CET) (envelope-from iljitsch@muada.com) In-Reply-To: References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <60C4A248E730F249990993E3B9BD44D80322B119@xmb-sjc-218.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0E99446F-F09C-474A-B403-EA95616A4995@muada.com> Content-Transfer-Encoding: 7bit From: Iljitsch van Beijnum Subject: Re: [RAM] Can we forget LISP, please? Date: Wed, 28 Feb 2007 23:01:03 +0100 To: "" X-Mailer: Apple Mail (2.752.2) X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL, BAYES_00, ILJQX_SUBJ_HUH autolearn=no version=3.0.2 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on sequoia.muada.com X-Spam-Score: -2.8 (--) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On 28-feb-2007, at 8:49, wrote: > i.e. the use of > cryptographically bound identities as IDs? It seems to me that LISP > would work rather well with CGAs as in SHIM6? But wouldn't that require changes to hosts? And if you accept that, why not simply adopt shim6 itself, with or without some modifications? (It's not like it's finished just yet.) > 2. Current practice allows only for ~64 crypto-bits in a CGA. It would > be better to carve out a portion of the IPv6 address space for > e.g. /28 > prefixes (for EID resolution aggregation) and ~100 bits for crypto. > Would be more secure and future proof. Like HIP, you mean? :-) _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 19:44:44 2007 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMZOH-0007bA-SG; Wed, 28 Feb 2007 19:43:25 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMYnz-0002mY-G8 for ram@iab.org; Wed, 28 Feb 2007 19:05:55 -0500 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMYnZ-0005Dx-Q1 for ram@iab.org; Wed, 28 Feb 2007 19:05:55 -0500 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 7BF9610F31A; Thu, 1 Mar 2007 01:05:26 +0100 (CET) Received: from [163.117.203.246] (unknown [163.117.203.246]) by smtp02.uc3m.es (Postfix) with ESMTP id 05E9410F323; Thu, 1 Mar 2007 01:05:25 +0100 (CET) Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: marcelo bagnulo braun Date: Wed, 28 Feb 2007 23:56:59 +0100 To: dino@cisco.com X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ram@iab.org Subject: [RAM] couple of questions about LISP X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Hi Dino, I have a couple of questions about LISP First one is about how would LISP work in the following situation. I assume we are using LISP1 Consider that we have a host A in a site a that has EID EIDA (which is globally routable in order to be able to bootstrap the initial EID-to-RLOC mapping) and RLOCA which is a different address. Suppose that site We have another host B located in a different site b that has a another locator RLOCB. Suppose that both site a and site b has multiple ISPs (at least two and they have several TR, for fault tolerance reasons) Suppose now that host B initiates a communication with Host A Host B sends a packet to host A The packet contains EIDA as dest add and EIDB as src addr The packet is processed by an ITRB1 close to site b Since we are in LISP1, the packet is forwarded as it is the packet reaches the ETRA1 close to site a and the ETR sends a ICMP packet back to the ITRB1 with the RLOCA information and the mapping between EIDA and RLOC is stored in ITRB1. Now bad things start :-) First there is a failure and EIDA is no longer reachable No problem with that, since ITRB1 has the information about alternative locators for host A, it will start sending tunneled packets using RLOCA as dest address in the outer header and the communication is preserved through this outage. However, now a second bad thing happens, which is that ITRB1 fails I assume that it is possible in LISP, that an alternative ITR ITRB2 is used for site B, so packets are rerouted to that backup ITRB1 for site b. But the problem is that packets that host b is sending contain EIDA as destiantion address which is unfortunatelly unreachable at this time. this was not a problem before because ITRB1 had the alternative locator information, but it has failed. The backup router ITRB1 does not contain the alternative locator information for EIDa (i.e. RLOCA), so how can the communication survive this outage? I mean, i guess that fault tolerance is the key feature and the LISP boxes cannot become a single point of failure, so i guess it should be possible to survive this type of situations Second one, in LISP 1,5 and in LISP 2 how do you think communication between a LISP host that is using non globally routable EIDs and legacy hosts non served by any LISP capable router would work? Thanks, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 20:49:11 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMaOA-0008O8-3u; Wed, 28 Feb 2007 20:47:22 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMaO7-0008Nu-UH for ram@ietf.org; Wed, 28 Feb 2007 20:47:21 -0500 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMaO6-0002hf-I7 for ram@ietf.org; Wed, 28 Feb 2007 20:47:19 -0500 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 28 Feb 2007 17:47:10 -0800 X-IronPort-AV: i="4.14,233,1170662400"; d="scan'208"; a="43976172:sNHT6596354745" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l211lAO4017229; Wed, 28 Feb 2007 17:47:10 -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 l211l7Uw019211; Wed, 28 Feb 2007 17:47:07 -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); Wed, 28 Feb 2007 17:47:07 -0800 Received: from [192.168.0.4] ([10.21.80.218]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Feb 2007 17:47:06 -0800 In-Reply-To: <82C79563-790E-4E8C-8EE8-074429B42B5E@muada.com> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <82C79563-790E-4E8C-8EE8-074429B42B5E@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9021D990-01EE-48DC-AEA6-7DD2DEF34ECA@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Can we forget LISP, please? Date: Wed, 28 Feb 2007 17:47:10 -0800 To: Iljitsch van Beijnum X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Mar 2007 01:47:06.0856 (UTC) FILETIME=[84C3A680:01C75BA3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2839; t=1172713630; x=1173577630; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=dino@cisco.com; z=From:=20Dino=20Farinacci=20 |Subject:=20Re=3A=20[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=yv9TNwQRrlFJuiIItduAxU+ltiUWhI9RUrb2XNjMGjU=; b=Y8ROmcL6Ip9/CgJqnp5DHzVyd1IuhRSOpXOMWs6eFBrGA6rWcczC2reRY22o7fVgmpTbzyR9 X+OvrwpfgU9X6fWA97j6L+rSG+XZefQwNtS0aACqPXFXsPtcqYwff8j0; Authentication-Results: sj-dkim-4; header.From=dino@cisco.com; dkim=pass (si g from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org >>> A DNS-like approach only works as long as you're talking to a >>> relatively small subset of all possible destinations. > >> For the reason you don't put ITRs (for prepending the locator >> header) in the ISP network. You put it at the source site. > > Then how do you get end-users to deploy those boxes? We haven't > exactly been successful in getting them to turn IPv6 on even though > they got it for free with the hardware they bought for IPv4. (At > least, a good number of them did.) They want ingress packet selection. They want more determinism how their packets come into their site. >> I personally am interested in playing with GSE to see how a >> different approach can be used but still router-based with no host >> changes. GSE could be just as easy to deploy as LISP but serves >> IPv6 only. > > Would be nice if someone could fill in the missing pieces to make > GSE a complete solution, though... Right, will come in due time. > You can of course always find more address bits by adding extra > tunnel headers, which also helps with keeping the whole thing more > backward compatible. This could actually work, but then we're back > at how to find outer tunnel addresses (LOCs) to go along with inner > tunnel addresses (IDs). Yep. >> Hmm. The BGP RIB is a sort of a cache. Anyways, the EID database >> can and must be highly aggregatable and since EID mappings won't >> change like ISP-connection-changes and links and nodes going up an >> down, there will not be entropy in the EID-prefix space. > >> So I think the EID cache could be considerably smaller and >> certainly so in many places. > > Aggregation is no magic bullet. What this gives you is the ability > to have a bunch of routers that handle 0/1 and another bunch of > routers that handle 128/1 so that each set only needs to know about > half the internet = the required parallelism. But you still need to > have the full global information in the aggregate set of routers, > so you're still dealing with large dynamic tables, the difference > is that when the tables get _too_ large you can add boxes. I am not following at all. But don't bother explaining. >>> I don't like having separate ID and LOC address spaces. I doubt >>> whether this will buy us anything useful, and I prefer having a >>> knob that I can turn from "every ID is a LOC" like we have now to >>> "complete separation" but also to settings somewhere in between >>> as required and desired. For this, IDs must remain able to >>> function as LOCs like they can today. > >> I think you just described LISP and didn't realize it. > > Could be, the draft isn't the easiest one to decipher... You are using a cipher that you don't need to use. ;-) Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 21:07:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMagw-0002sf-Dj; Wed, 28 Feb 2007 21:06:46 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMagv-0002sa-G8 for ram@ietf.org; Wed, 28 Feb 2007 21:06:45 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMagt-0004C3-Dy for ram@ietf.org; Wed, 28 Feb 2007 21:06:45 -0500 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by sj-iport-2.cisco.com with ESMTP; 28 Feb 2007 18:06:42 -0800 X-IronPort-AV: i="4.14,233,1170662400"; d="scan'208"; a="363420136:sNHT51624264" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l2126eLB006150; Thu, 1 Mar 2007 03:06:41 +0100 Received: from xbh-hkg-412.apac.cisco.com (xbh-hkg-412.cisco.com [64.104.123.69]) by hkg-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l2125mUX007818; Thu, 1 Mar 2007 10:06:36 +0800 (CST) Received: from xfe-hkg-411.apac.cisco.com ([64.104.123.70]) by xbh-hkg-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 10:06:20 +0800 Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Mar 2007 10:06:19 +0800 Received: from mstenber by emakko.cisco.com with local (Exim 4.62) (envelope-from ) id 1HMag5-0007Gt-6m; Thu, 01 Mar 2007 11:05:53 +0900 From: Markus Stenberg To: Dino Farinacci Subject: Re: [RAM] Can we forget LISP, please? Organization: cisco Systems, Inc. References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> Date: Thu, 01 Mar 2007 11:05:53 +0900 In-Reply-To: (Dino Farinacci's message of "Wed, 28 Feb 2007 13:12:11 -0800") Message-ID: <87r6s9n2f2.fsf@emakko.cisco.com> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 01 Mar 2007 02:06:19.0965 (UTC) FILETIME=[34121ED0:01C75BA6] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4312; t=1172714801; x=1173578801; c=relaxed/simple; s=amsdkim2001; 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[RAM]=20Can=20we=20forget=20LISP,=20please? |Sender:=20; bh=E7MaY3uR4UeV9xcWNNq4hV91DzxfAE/vDO6sdL6MMyA=; b=WzflL9N9m1Bo9vf664/aZJyPDV35SnekAo2lE1p96BYSE4+kK+bgB1yICtfDVxNf50nKCo2p YHuQZswHp/13X8kh6Cz2MZgDQ42Oa04bHqX6CfjDw3Grb5AGfA9BdnW9; Authentication-Results: ams-dkim-2; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org Dino Farinacci writes: >>> They need something trivially to deploy and they want it >>> quickly. If you want a full fledge solution, then go look at shim6, >>> you know how long that is taking to get deployed. >> >> The internet isn't going to melt down tomorrow or next week. The >> IETF is fundamentally > > Right, but we have to start development now so we are ready when it > does. This opportunity is taking a proactive rather than reactive > approach. If we wait to reactive we will be rushed to do the right > solution. Well, what I'm mostly questioning is the IPv4 angle; no matter how you cut it, the solution that includes IPv4 will be a horrid hack (i.e. effectively everyone will be NAT'ed) and still not maintain the end-to-end nature of the traffic (if one of the boxes along the way loses state, or you want multiple redundant paths, I don't see elegant recovery path just from the IPv4 traffic). IPv6 'big' prefix EID-space (something like Orchid) at least would work while actually providing for end-to-end consistent addresses.. These caveats apply at least if the solution implemented with no changes in endpoints approach that LISP seems to advocate. So why is this desirable approach? From my point of view, any solution that cannot be really end-to-end isn't desirable. And that requires globally unique identifiers, and that requires more bits than IPv4 unfortunately has (assuming you don't have central identifier repository, which doesn't sound scalable to me). Assuming both our machines picked 10.0.0.1 'identifier', how will they talk to each other without NAT again? Main problem with any non-host-based solution (from my limited understanding) is that you wind up in NATland whether you're talking IPv4 or IPv6; and you have rather difficult time tying the identifiers to locators securely. On the other hand, using something with crypto basis on hosts (CGA, HIP) you can actually get trusted identifiers.. I've been long-time fan of HIP due to it actually providing proof of ownership of the identifier you're communicating with. How does LISP address this? I don't see this angle in current draft at all. Similar proof of ownership should be needed for also say, doing DHT of the EIDs (or the ICMP messages for that matter), and without cryptographic proof of ownership the system would be simply broken. I'm not saying toss LISP, but I'd rather see version of it that addresses _all_ of the issues HIP/SHIM6 have played with over the years, and then call it 'simple', or better yet, 'elegant'.. *grin* I'd argue that IPv6 deployment is hard because it requires changes to both hosts and routers in the middle, but endpoints are happily routing around network damage (NATs, firewalls and other miracles within application gateways) nowadays and if someone pushed it one level or two down in the host stack, I couldn't be happier. Having every application do their own high-availability mobility, security and end-to-end communication hacks does get old after all. Microsoft put IPv6+toredo in Vista, I'd have more faith in their next OS doing the right thing than some router-only solution actually having all characteristics that at least I want. Disclaimer: My home and office setups are Microsoft-free, but that's 'the' host OS these days; cellphone OSes might be getting there sooner or later, but they're seldom outside walled gardens anyway so I'm not sure if they count. >> work on the parts concurrently, we should have something ready for >> review this year and all the details hammered out and some early >> implementations next year. > > I think this is actually happening. I personally am interested in > playing with GSE to see how a different approach can be used but > still router-based with no host changes. GSE could be just as easy to > deploy as LISP but serves IPv6 only. > > I was wondering if anything thinks GSE could work for IPv4. Comments? > It will limit the number of connections a host can make globally but > I want to throw it out and see what folks think? I don't think it'd limit number of connections enough, but re-using whole IPv4 space is not an option, I think, and without that, you have simply too few bits? Cheers, -Markus _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 21:18:15 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMarg-0007N4-64; Wed, 28 Feb 2007 21:17:52 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMare-0007Mf-D5 for ram@ietf.org; Wed, 28 Feb 2007 21:17:50 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMarb-0004rs-Rf for ram@ietf.org; Wed, 28 Feb 2007 21:17:50 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id 3D06D53E1B5; Wed, 28 Feb 2007 21:17:47 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id FsyCBJtw1kOq; Wed, 28 Feb 2007 21:17:42 -0500 (EST) Received: from [172.23.10.228] (nat-service4.juniper.net [66.129.225.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id 1BE7D53E072; Wed, 28 Feb 2007 21:17:40 -0500 (EST) In-Reply-To: References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] Can we forget LISP, please? Date: Thu, 1 Mar 2007 10:17:37 +0800 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mar 1, 2007, at 5:12 AM, Dino Farinacci wrote: > Hmm. The BGP RIB is a sort of a cache. Huh? How do you figure? --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Feb 28 23:34:19 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMcxg-0006Sl-Ck; Wed, 28 Feb 2007 23:32:12 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HMcxf-0006Sg-C5 for ram@ietf.org; Wed, 28 Feb 2007 23:32:11 -0500 Received: from bgp.nu ([64.27.28.76]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HMcxe-0005nh-4N for ram@ietf.org; Wed, 28 Feb 2007 23:32:11 -0500 Received: from localhost (bgp.nu [64.27.28.76]) by bgp.nu (Postfix) with ESMTP id C310753E1B5; Wed, 28 Feb 2007 23:32:00 -0500 (EST) X-Virus-Scanned: amavisd-new at bgp.nu Received: from bgp.nu ([64.27.28.76]) by localhost (bgp.nu [64.27.28.76]) (amavisd-new, port 10024) with LMTP id tArg95WB13kI; Wed, 28 Feb 2007 23:31:51 -0500 (EST) Received: from [172.23.10.228] (nat-service4.juniper.net [66.129.225.151]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by bgp.nu (Postfix) with ESMTP id A240B53E072; Wed, 28 Feb 2007 23:31:50 -0500 (EST) In-Reply-To: <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> References: <9326355A-F230-43BB-92FD-56FB7FEF9726@muada.com> <1B6E0758-4A4B-48CE-9695-1236A49930AD@cisco.com> <03517D4B-C7B7-462C-B735-C70CE19747B8@muada.com> <5BE0C06B-0A5F-4057-92EC-D90582B08FB8@bgp.nu> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: "John G. Scudder" Subject: Re: [RAM] Can we forget LISP, please? Date: Thu, 1 Mar 2007 12:31:46 +0800 To: John G. Scudder X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: ram@ietf.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org On Mar 1, 2007, at 10:17 AM, John G. Scudder wrote: > On Mar 1, 2007, at 5:12 AM, Dino Farinacci wrote: >> Hmm. The BGP RIB is a sort of a cache. > > Huh? How do you figure? Let me rephrase that: No, it's not. --John _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram