From ram-bounces@iab.org Sun Apr 01 03:21:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXuLP-0005ny-DI; Sun, 01 Apr 2007 03:19:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXuLO-0005nt-Gp for ram@iab.org; Sun, 01 Apr 2007 03:19:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HXuLN-00019C-73 for ram@iab.org; Sun, 01 Apr 2007 03:19:18 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2007 00:19:16 -0700 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 l317JGU4007043; Sun, 1 Apr 2007 00:19:16 -0700 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 l317JGMF021825; Sun, 1 Apr 2007 07:19:16 GMT 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); Sun, 1 Apr 2007 00:19:16 -0700 Received: from [192.168.0.100] ([10.21.82.185]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 00:19:16 -0700 In-Reply-To: <5.0.0.25.2.20070331205700.033d1290@zircon.juniper.net> References: <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <5.0.0.25.2.20070331205700.033d1290@zircon.juniper.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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 1 Apr 2007 00:19:15 -0700 To: Ross Callon X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 01 Apr 2007 07:19:16.0230 (UTC) FILETIME=[0E670A60:01C7742E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1101; t=1175411956; x=1176275956; c=relaxed/simple; s=sjdkim3002; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=pMcC11bMklJYxi2DBbr4FxLITv8EWJyZHoIWCUx0enM=; b=ZN8h7Z74rHB7f5m1ArRdb4kaAwLudFPWUgCnpXWxUzDdgGg8C75r5O85XVlIM30V1l6ykU/n rjeWFFwFH+X4JCLRkMjCoMcfohsGo6xC27ZCNEHMuqeEA/L24B1ioscS; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Mar 31, 2007, at 6:31 PM, Ross Callon wrote: > (1) You are going to make the data plane MUCH slower; or > (2) You are going to very lightly load the data plane; or > (3) You are going to implement the control aspects of LISP > somewhere other than on the central processor; or > (4) You are going to build routers whose central processor is > several orders of magnitude faster than on current routers; or > (5) You feel that you can implement LISP on a PE router > with a load on the control plane which is at least 10,000 > times smaller than the load on the data plane (so that each > time a packet goes to the control plane, on the average there > are 10,000 or more packets that will be forwarded via the data > plane before the next packet needs to go to the control plane) > > I am guessing that the answer is either (5), or perhaps (3), or > (6) You are going to deploy LISP closer to the edge (and NOT > in the PE router). If I can paraphrase you, Ross, doing packet forwarding at 10Mpps doesn't scare me. ;-) Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 01 08:04:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXykp-0000ID-Bu; Sun, 01 Apr 2007 08:01:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HXykn-0000Eh-QN for ram@iab.org; Sun, 01 Apr 2007 08:01:49 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HXykl-0005B9-Ny for ram@iab.org; Sun, 01 Apr 2007 08:01:49 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 6392B59DA1; Sun, 1 Apr 2007 22:01:43 +1000 (EST) Message-ID: <460F9F1B.8030600@firstpr.com.au> Date: Sun, 01 Apr 2007 22:01:31 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 Subject: [RAM] ID: SRAM-based IP forwarding eliminates the need for Route Aggregation 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 should have found and joined this list much earlier. I apologise to to list members who have already received this announcement directly. Below is the same as what I wrote to many list members, but with a new introduction. I have written "draft-whittle-sram-ip-forwarding-01" (30 March 2007) which is best accessed at: http://www.firstpr.com.au/ip/sram-ip-forwarding/ since at present, the IETF system only has version 00. This is a solution to what I think is the most serious part of the routing and addressing problem: how to classify and forward packets according to hundreds of thousands (and later millions) of RIB rules, ideally in a single clock-cycle with low power, simple hardware. There are no changes required to end-user software or to protocols. This proposal, if brought to fruition, would involve: 1 - A new standard for future routers for the DFZ, specifying some simple requirements which can easily be achieved with a an additional packet classification system, based on a USD$70, 72 Mbit Static RAM in each interface (or two chips for larger routers). 2 - A long term agreement to maintain the current /24 limit on IPv4 BGP advertised routes, a similar limit for IPv6 - such as /35. 3 - The definition of a relatively small (but still enormous, for all practical purposes) range of IPv6 address space where the system will operate. Then, IPv4 space and the defined range of IPv6 space can be assigned freely to ISPs and AS end-users (as Provider Independent Addresses). It can then be advertised freely in potentially millions of separate prefixes within the /24 or /35 limits, without regard to route aggregation, network topology etc. This would eliminate many constraints on address management and usage, enabling much more efficient use of the address space to be made. This scheme can be deployed incrementally, as routers are replaced over the 2010 to 2014 period. The the full benefits of very large numbers of freely advertised prefixes will appear once the new generation of routers becomes ubiquitous in the DFZ. I propose a simple Static RAM based architecture for the packet classification system of all routers in the Default Free Zone - ideally to be a standard part of new high-end routers from 2010 onwards. This would not replace the current forwarding system, but would enable each router interface to classify Internet user traffic packets in a single clock cycle, determining which interface each packet should be sent to. Once these routers are widely deployed, address space can be assigned and prefixes advertised without concern about route disaggregation. This will allow much greater flexibility in address utilisation, including freedom to advertise IPv4 subnets down to /24 without regard to network topology. This won't solve every problem in routing and addressing, but I think it will solve the most difficult one: the need for rapid forwarding of each packet according to the rules for potentially millions of separately advertised prefixes. Routers will still need larger RIB CPU and memory capacities to handle the much larger number of BGP advertised prefixes which this proposal is intended to bring about. There are also potential difficulties with the stability of BGP with a greatly increased number of routers and advertised prefixes. The system can classify incoming packets at 250 million packets a second, using 7/8 of a single 72 Mbit Static RAM chip for each interface of routers with up to 14 interfaces. These chips are currently in mass production and cost about USD$70. Power consumption would probably be about 1 watt for a 40Gbps interface. Two chips would be needed in each interface for routers with between 15 and 510 interfaces. For IPv4, the system provides a separate memory location to hold the Forwarding Equivalence Class (FEC) for each of the 14,680,064 /24 prefixes from 0.0.0.0 to 223.225.225.0. The idea is to handle all Internet user packets in the DFZ in this way, with the few packets (such as for inter-router traffic) whose forwarding is governed by rules for prefixes longer than /24 being handled by the router's conventional packet classification techniques. Each /24 in which conventional techniques needed to be applied would be flagged as such by having a particular value of FEC in that /24's SRAM location. The 32 bit IPv4 address length and the convention of limiting BGP prefixes to no longer than /24 result in 24 bits of address to consider when determining which interface to forward each packet to. It is a fortunate coincidence that this is ideally suited to current production SRAMs. For IPv6, FEC depends on too many address bits for this SRAM approach to be practical. I propose some alternatives, such as a special subset of 2000::/3 in which routers would use SRAM forwarding. This address space would have no requirement for route aggregation, and I anticipate that in the long term most IPv6 traffic would migrate to this range. It may be possible to have a good IPv6 arrangement - such as SRAM IP forwarding for 2 million /35s, each of which provides 8192 /48 user networks, (16 billion user networks) - simply by using the 1/8 of the SRAM which is not required for IPv4. This would allow Provider Independent address assignments for hundreds of thousands of ISPs and AS end-users, for both IPv4 and IPv6, with fast, low-power packet forwarding no matter how much the address space is broken up for BGP advertised prefixes, within the /24 or /35 limits. One important benefit of the new scheme would be that addresses could be assigned by RIRs in small increments to ISPs and AS end-users, since it would not matter how much route disaggregation results. This would make it much easier to use available address space efficiently, since there would be no need to assign big blocks based on a several year projection of each user's needs. I have a background in electronics, programming, telecommunications technical writing and privacy advocacy. I have worked on telecommunications standards committees, but I have not been involved in the IETF before. This is an unusual proposal: to coordinate router design, Internet address management policy and BGP routing policy according to the capacity of specific memory chips. I hope you find it interesting! Regards - Robin Melbourne Australia http://www.firstpr.com.au/ip/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 01 12:58:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3Kd-0007Mk-1S; Sun, 01 Apr 2007 12:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3Kb-0007Mf-DA for ram@iab.org; Sun, 01 Apr 2007 12:55:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY3Ka-0003PI-2b for ram@iab.org; Sun, 01 Apr 2007 12:55:05 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2007 18:54:57 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l31GsvCj013878; Sun, 1 Apr 2007 18:54:57 +0200 Received: from [212.254.247.4] (ams3-vpn-dhcp4390.cisco.com [10.61.81.37]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l31GsmlZ023553; Sun, 1 Apr 2007 16:54:52 GMT Message-ID: <460FE3D6.3040300@cisco.com> Date: Sun, 01 Apr 2007 18:54:46 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2928; t=1175446497; x=1176310497; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=92y3K3pPVvYPt2ojWizWLZxZV7qLsN9FE1MP1SDnwao=; b=rG8naIpWbFDgRSfFGM1Sq6/9jiXz07hOhIZLLjUXe7L3zWAG8fu2SefRzfZb1/ym12So+yMK O9c1tEaor7VNllSf8FBoWLlAym3qRv2rdAp9X/6FlGj5GZgC/JmrYsOJ; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 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 Dave, >> Lookups are a non-starter because of the lookup latency and what you >> do with a packet on a cache miss > > I wonder if the folks who argued against moving from HOSTS.TXT to the > DNS used the same rationale... :-) Remember, with LISP we're talking about ROUTERS switching PACKETs and not END HOSTS establishing a communication (be it UDP, TCP, SCTP, or whatever). Again, at the end host level you're correct, and this is precisely what HIP does. If that's what you want, then you're half way home because the HIP people have running code and a head start on a bunch of problems in that space. > > More seriously, the vast majority of people and processes already have > to deal with lookup latency on the initiation of an Internet > transaction since IP addresses aren't generally used by people or > applications. > > As for what to do with cache misses, you do the same thing you do with > any datagram-based system: you buffer and when you can't buffer you > drop based on some algorithm and assume the packet will be > retransmitted. If you have the mapping service at the edge, you don't > need to use static RAM, but instead can use cheap commodity DRAM and > have a really big cache. Whether you use SRAM, DRAM, SDRAM, or good old core memory is not my concern. My concern is latency in establishing a connection when everything is in a nominal state, particularly due to an off-the-box lookup. >> We want something that is akin to the RADB (perhaps a big table that >> can be diffed periodically), but to be sure is administered easily by >> end systems. > > I don't think this is what we want. I could see an argument for a > dynamic table of identifier to locator mappings similar to the routing > table being propagated by flooding. I could even see an argument for > something done along the lines of P2P file sharing apps like > BitTorrent. I could (of course) see a pull based mechanism that has > characteristics similar to the DNS. But something like the > centralized, largely static RADB? The security model is wrong. > People forget to update it. Who would run/maintain it? Etc. If you are going to do an ID/Locator split at all you had better have answers to this basic question: how do you establish authority for the mapping? Yes, you can do it with DNS, but that will produce unacceptable latency. I won't accept that a DHT will solve this problem until I see a DHT that solves this problem without the "and magic happens here" part. The reason people didn't update the RADB was simply because it didn't matter and there was no programmatic operational tie to anything going on with the routing system. And yes, you do want to worry about security, so the authority had better sign the updates prior to distribution. Then distribution itself becomes less of a concern. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 01 12:58:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3NX-00021W-Qx; Sun, 01 Apr 2007 12:58:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HY3NW-00021O-9I for ram@iab.org; Sun, 01 Apr 2007 12:58:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HY3NT-0004jR-KC for ram@iab.org; Sun, 01 Apr 2007 12:58:06 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 01 Apr 2007 18:58:03 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l31Gw2DX014205; Sun, 1 Apr 2007 18:58:02 +0200 Received: from [212.254.247.4] (ams3-vpn-dhcp4390.cisco.com [10.61.81.37]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l31Gw2lZ023854; Sun, 1 Apr 2007 16:58:02 GMT Message-ID: <460FE498.6020906@cisco.com> Date: Sun, 01 Apr 2007 18:58:00 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Ross Callon Subject: Re: [RAM] Incremental Deployment of LISP References: <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> In-Reply-To: <5.0.0.25.2.20070331215849.034161c0@zircon.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=625; t=1175446682; x=1176310682; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=uL99WiRZlUpN3LIWClupwnos2ZoBQqu5ZRlxd0JwljQ=; b=uAYPv1ANS1nsQFdU3l5Y/gsJZnsLMTf377eiRsMHVm0rcEyMCPNwFJcOTFL+XqBbXxgZc/O0 HhtnxRUESX/DTaQn3DhgBk3cuHEWZjE5qnp9vSdBb25D76tDlb4IjHZy; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Cc: "Templin, Fred L" , 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 Ross Callon wrote: > I am worried about a full PUSH due to the potential size of the > mapping table (see the email that I just sent). If you can deploy > LISP very close to the host then I agree that this particular > problem goes away. While I think that's a reasonable fear, I believe there are solutions to this through incremental updates, etc. If it turns out that the cost of having a redundant connection is that you need a beefier router, I can live with that because it places the cost of multihoming on the parties who are enjoying the benefits, which is a substantial change from today. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 01 22:45:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCUS-0004rM-W7; Sun, 01 Apr 2007 22:41:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCUR-0004rE-3H for ram@iab.org; Sun, 01 Apr 2007 22:41:51 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYCUN-0001eN-Er for ram@iab.org; Sun, 01 Apr 2007 22:41:51 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 02 Apr 2007 21:09:37 +0530 X-IronPort-AV: i="4.14,359,1170613800"; d="scan'208"; a="77537893:sNHT51016500" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l322fhDX015893; Mon, 2 Apr 2007 10:41:43 +0800 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 l322fSjg004601; Mon, 2 Apr 2007 02:41:42 GMT 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); Mon, 2 Apr 2007 10:41:08 +0800 Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:41:08 +0800 Received: from mstenber by emakko.cisco.com with local (Exim 4.62) (envelope-from ) id 1HYCRz-0001wc-W8; Mon, 02 Apr 2007 11:39:20 +0900 From: Markus Stenberg To: Eliot Lear Subject: Re: [RAM] Incremental Deployment of LISP Organization: cisco Systems, Inc. References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> Date: Mon, 02 Apr 2007 11:39:19 +0900 In-Reply-To: <460FE3D6.3040300@cisco.com> (Eliot Lear's message of "Sun, 01 Apr 2007 18:54:46 +0200") Message-ID: <877isva4a0.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: 02 Apr 2007 02:41:08.0670 (UTC) FILETIME=[5E4135E0:01C774D0] Authentication-Results: hkg-dkim-1; header.From=mstenber@cisco.com; dkim=neutral ( ssp=~; ); 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 Eliot Lear writes: > Remember, with LISP we're talking about ROUTERS switching PACKETs and > not END HOSTS establishing a communication (be it UDP, TCP, SCTP, or > whatever). Again, at the end host level you're correct, and this is > precisely what HIP does. If that's what you want, then you're half > way home because the HIP people have running code and a head start on > a bunch of problems in that space. Indeed. In end host solutions, something very like HIP seems to be the way to go. However, cost-benefit analysis of that remains to be seen. > If you are going to do an ID/Locator split at all you had better have > answers to this basic question: how do you establish authority for the > mapping? Yes, you can do it with DNS, but that will produce > unacceptable latency. I won't accept that a DHT will solve this > problem until I see a DHT that solves this problem without the "and > magic happens here" part. The reason people didn't update the RADB > was simply because it didn't matter and there was no programmatic > operational tie to anything going on with the routing system. > > And yes, you do want to worry about security, so the authority had > better sign the updates prior to distribution. Then distribution > itself becomes less of a concern. I don't think anyone _has_ working push model that scales. DNS is pull; DHT is pull; BGP is push (but doesn't scale too well). Authenticating 'push' traffic even for current prefix updates is a hard problem [1]; doing that for 'push' of whole identifier space (or just those few millions of PI-ish multihomed prefixes people envision in future) sounds quite hard. (Think few crypto ops per prefix, if you want to be really paranoid, and at router bootup needing to go through the whole prefix space - no thanks :-> And if you delay it, you open yourself up for all sorts of funny resource exhaustion attacks..) I've been thinking on this topic quite a lot, and only conclusions I've reached is that you can either get - one-level lookup hierarchy (say, global DHT), or - security, or - push model. And not easily more than one of those. DNS for example is multilevel pull hierarchy with some security in it (DNSSec); most DHTs are pull models without security. BGP has global hierarchy and push model but it doesn't scale. For what it's worth, I think that some sort of multilevel model with decent security is the thing to go for, with the most global levels being possibly push model, the rest obviously pull as you don't want to push end host state (or even possibly customer PI address state) onward. Cheers, -Markus [1] Meaning, authenticating for example cryptographically signed per-prefix updates, not the raw data traffic itself. TCP-MD5, or IPsec works perfectly well for traffic but gives no guarantee of the original origin of the update. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 01 22:49:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCbf-0001F8-K9; Sun, 01 Apr 2007 22:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYCbe-0001Ex-4Q for ram@iab.org; Sun, 01 Apr 2007 22:49:18 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYCbc-0003MZ-OE for ram@iab.org; Sun, 01 Apr 2007 22:49:18 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 04:49:16 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l322nDue015572; Mon, 2 Apr 2007 04:49:13 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l322mvlp024305; Mon, 2 Apr 2007 02:49:13 GMT Received: from xbh-hkg-411.apac.cisco.com ([64.104.123.72]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 04:49:10 +0200 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); Mon, 2 Apr 2007 10:48:39 +0800 Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:48:38 +0800 Received: from mstenber by emakko.cisco.com with local (Exim 4.62) (envelope-from ) id 1HYCZG-0001ww-FR; Mon, 02 Apr 2007 11:46:50 +0900 From: Markus Stenberg To: Dino Farinacci Subject: Re: [RAM] Re: ICMP error dependency in LISP Organization: cisco Systems, Inc. References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> Date: Mon, 02 Apr 2007 11:46:50 +0900 In-Reply-To: <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> (Dino Farinacci's message of "Sat, 31 Mar 2007 01:13:00 -0700") Message-ID: <873b3ja3xh.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: 02 Apr 2007 02:48:39.0048 (UTC) FILETIME=[6AB37080:01C774D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2851; t=1175482153; x=1176346153; c=relaxed/simple; s=amsdkim1002; 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]=20Re=3A=20ICMP=20error=20dependency=20in=20LISP |Sender:=20; bh=M5ZW736xgIWlDSoY94gx/0MAiAS4VsSq0TJjBLf7K1Q=; b=astogMGom6uxGk08UvlSEfXKqvMucSrHZiUww3y0yu1deIGGaJY1q8Zowd2RgZ5Ke9LTUbO2 BgbGDoQpy5ANv0vjRgau5Z2zAlDWUJKa/DSEFd6Yx+jnzbsJJ4F/cIn8; Authentication-Results: ams-dkim-1; header.From=mstenber@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: Margaret Wasserman , 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 Farinacci writes: >> d) some poor firewall or ACL filters out the ICMP message at the ICMP >> originator's domain, in transit, or at the recipient's domain? > The protocol needs feedback. If you choose UDP to return the mapping > or error message, those could get filtered as well. There is no magic > here, you have to fix the filters. > > If we let these things get in the way, nothing will be able to get > deployed. So far most of the solutions IETF has been working on has been routing around the damage (NATs -> NAT-traversal, ICMPs lost -> don't rely on them) rather than mandating policy. Mandating a policy (BCP-38) hasn't had much of a success, unfortunately. >> e) the ICMP error gets lost in the network (transient routing loop, >> congestion, etc.). ICMP delivery is after all unreliable. > > Oh well, would you rather have a TCP connection between active ITR/ > ETR pairs, I don't think so. > > ARP requests and replies are unreliable. > DNS requests and replies are unreliable. > SNMP packets are unreliable. > > We have lived with this. The Internet is best-effort and I think it > does a good job of being "best". I think you're nitpicking; ICMP is about as reliable communication media as sending the messages using RFC1149 in modern internet - certainly, ping/traceroute work for some definition of works, but PMTU-related seems to break quite frequently. And do you really believe you can get everyone to fix their filters to get 'incrementially' deployed solution working as well as current state? This sounds like a non-starter to me. The 'unreliable' by virtue of unreliable packets is orders of magnitude more reliable than ICMP in the modern internet. (rate limiting, filtering, etc, all aimed at dropping excess ICMP traffic.) >> While participating in Transport Area working groups (e.g., TCPM) >> I've had an.. opportunity to hear rants about ICMP, for example, >> that it should be considered completely optional and anything that >> requires ICMP to work is broken; at best, ICMP should be an >> optimization mechanism. > What would you suggest as an alternative that won't have the same > issues? If you're designing a new protocol, might as well get a new protocol number for it (if you're really not afraid of filters), or use UDP (if you are). >> I'm not sure if I completely agree with these, but for sure I >> wouldn't built a system that had a very strong requirement for ICMP >> error generation and propagation. > The messages were defined originally to be of value. Yes, they have > been abused over the years, but the intent of the original designers > was to help the network. The LISP authors plan to continue to use ICMP. Well, then all I can tell you is, good luck, you will need it. :-) Cheers, -Markus _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 01:44:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFJs-0003HW-E8; Mon, 02 Apr 2007 01:43:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFJq-0003HJ-CW for ram@iab.org; Mon, 02 Apr 2007 01:43:06 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYFJp-0002tW-2p for ram@iab.org; Mon, 02 Apr 2007 01:43:06 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 07:43:04 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l325h4rS002431; Mon, 2 Apr 2007 07:43:04 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp85.cisco.com [10.61.64.85]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l325h3lZ011255; Mon, 2 Apr 2007 05:43:03 GMT Message-ID: <461097E5.6090307@cisco.com> Date: Mon, 02 Apr 2007 07:43:01 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Markus Stenberg Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <877isva4a0.fsf@emakko.cisco.com> In-Reply-To: <877isva4a0.fsf@emakko.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1760; t=1175492584; x=1176356584; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=PO/0QX9thrV2Qy8mmajADRGvtvcM3lF8TFqMkOnXYv4=; b=R2BKQlMaY7xRMVgb83vkiy7U7rgvxACrREeP3QPeS/exJ3gBoVss/wghILkzvgKHfxJC7QRl VoLpKDpx6VpwQkDiJeVoktD4NZjdIvmAzF/z8nP2zcIbQN98QrE+DOC1; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 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 Markus Stenberg wrote: > I don't think anyone _has_ working push model that scales. DNS is pull; DHT > is pull; BGP is push (but doesn't scale too well). > DNS demonstrates that the difference between push and pull isn't so far as one might think. Consider the case when a primary server for a zone sends out a notify for a zone. Is that push or pull? I'm not worried about push or pull. I believe we can crack this nut, if the rest of LISP works out well. > Authenticating 'push' traffic even for current prefix updates is a hard > problem [1]; I really can't stress this enough that has to be a different problem, or the game is really over. For one, you do not need to sign each prefix separately. An authority needs to sign an update which may contain many mappings. Second, the number of updates required in a period of time has to be considerably smaller - BY SEVERAL ORDERS OF MAGNITUDE - or we would have failed in our primary engineering objective of better scaling the routing system. So, start by thinking about updates no more than once an hour and work that are signed by an authority. In such a circumstance you can even use a combination of push and pull, where SPs pull and then push to their customers, or customers themselves pull from SPs who are pushed updates. Either will scale, and most of the technology exists for both. > For what it's worth, I think that some sort of multilevel model with decent > security is the thing to go for, with the most global levels being possibly > push model, the rest obviously pull as you don't want to push end host > state (or even possibly customer PI address state) onward. > That is one perfectly feasible possibility. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 02:14:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFmi-0005rQ-MQ; Mon, 02 Apr 2007 02:12:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFmg-0005od-G4 for ram@iab.org; Mon, 02 Apr 2007 02:12:54 -0400 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 1HYFmd-0007OT-62 for ram@iab.org; Mon, 02 Apr 2007 02:12:54 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 01 Apr 2007 23:12:51 -0700 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 l326Cobp002853; Sun, 1 Apr 2007 23:12:50 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l326CjZT003440; Mon, 2 Apr 2007 06:12:46 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:12:45 -0700 Received: from [192.168.0.4] ([10.21.153.64]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:12:44 -0700 In-Reply-To: <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 1 Apr 2007 23:12:48 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 06:12:44.0899 (UTC) FILETIME=[EDCC0330:01C774ED] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=723; t=1175494370; x=1176358370; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=v1phLv7nMs3b097RPlXxdnsIXTjTF+7wFwGaj6u5Iug=; b=dOsQvPZmjVvQJn5rTdWDSglaF71Mb8a4qmASSSbO3+3Bj2y6euavApL8DpjQsRaEXwI188qf Il//NUbLch1tGZ7ghQ8crO2CdLyv4uAug8d57VkjixjTncR4zqsPdFfLLWUsktXwzm7hhNWcIE gM9itLphMxLvPSRy6Tu6YIvjk=; 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: 1ac7cc0a4cd376402b85bc1961a86ac2 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'm not yet convinced that this is really a requirement. Consider > what you're asking: the ability to TE on a per-site basis, given > that traffic is already assigned to PA prefixes. Typically in the > past, ISPs have wanted to do TE within another providers prefix, > and thus we have more specifics. This is incredibly important for > managing peering ratios and the like. However, applying TE on > multi-homed PI sites seems like it would be much less important > requirement. For the LISP model, packets that get to a TE-ITR do not have PI addresses in the outer DA. Those have been buried by having a ITR from the source site encapsulate putting locators in the outer DA. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 02:20:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFtV-0002d6-7Y; Mon, 02 Apr 2007 02:19:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFtT-0002cw-Mh for ram@iab.org; Mon, 02 Apr 2007 02:19:55 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYFtS-0008RL-CR for ram@iab.org; Mon, 02 Apr 2007 02:19:55 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 01 Apr 2007 23:19:53 -0700 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 l326Jr48000706; Sun, 1 Apr 2007 23:19:53 -0700 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 l326JiMF014172; Mon, 2 Apr 2007 06:19:49 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:19:44 -0700 Received: from [192.168.0.4] ([10.21.153.64]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:19:44 -0700 In-Reply-To: <873b3ja3xh.fsf@emakko.cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> <873b3ja3xh.fsf@emakko.cisco.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] Re: ICMP error dependency in LISP Date: Sun, 1 Apr 2007 23:19:48 -0700 To: Markus Stenberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 06:19:44.0462 (UTC) FILETIME=[E7E03EE0:01C774EE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1164; t=1175494793; x=1176358793; 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=20ICMP=20error=20dependency=20in=20LISP |Sender:=20; bh=3wL/0PS/q9+nNR2h7XM+LN6qBVpV/VpJLYxXFjSYQRE=; b=jyhIP7gi3H0APVObmdg7DakRrjkH5/rEUgCwwvoHj8Ove49j6gDezRgf73CJkJtjpPAq4ATu sLAOwoVEkY3PF89GMEYizdj117XIxjS3/RzPjHl3ZgUf5xphy6J9AZnH; 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: 52e1467c2184c31006318542db5614d5 Cc: Margaret Wasserman , 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 sounds like a non-starter to me. The 'unreliable' by virtue of > unreliable packets is orders of magnitude more reliable than ICMP > in the > modern internet. (rate limiting, filtering, etc, all aimed at dropping > excess ICMP traffic.) There is reliability in the system. The next non-rate-limited data packet will be responded to with an ICMP transmission by the ETR. >>> While participating in Transport Area working groups (e.g., TCPM) >>> I've had an.. opportunity to hear rants about ICMP, for example, >>> that it should be considered completely optional and anything that >>> requires ICMP to work is broken; at best, ICMP should be an >>> optimization mechanism. >>> >> What would you suggest as an alternative that won't have the same >> issues? >> > > If you're designing a new protocol, might as well get a new > protocol number > for it (if you're really not afraid of filters), or use UDP (if you > are). This is a simple fix. We can do this. > Well, then all I can tell you is, good luck, you will need it. :-) Let me repeat, this is a prototype, the end result could look very different. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 02:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFxf-00050J-Kd; Mon, 02 Apr 2007 02:24:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYFxe-0004tc-4P for ram@iab.org; Mon, 02 Apr 2007 02:24:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYFxc-0000d0-Qx for ram@iab.org; Mon, 02 Apr 2007 02:24:14 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 01 Apr 2007 23:24:14 -0700 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 l326OCxP017655; Sun, 1 Apr 2007 23:24:12 -0700 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 l326O7wn001821; Mon, 2 Apr 2007 06:24:08 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:24:07 -0700 Received: from [192.168.0.4] ([10.21.153.64]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:24:06 -0700 In-Reply-To: <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Sun, 1 Apr 2007 23:24:10 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 06:24:06.0821 (UTC) FILETIME=[84410D50:01C774EF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1262; t=1175495052; x=1176359052; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=7QGjmGcR2zRyt9NtzT2wwjRM3WiVflREO5Zaamm336Q=; b=hMM35WEPFbO0DOdQPt1AKZ5q2qS/GgpB828ScJ72N+QjgEZZaOyR4F0WWzqCWygdH8fw83B9 oA4bMNZ5Hs9kt5cUNqzeIUHMV+UufGaJSjoEA40dL4FzGxtHwEs5/QOH; 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: 97adf591118a232206bdb5a27b217034 Cc: "Templin, Fred L" , 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 think this heavily depends on what scenario you are considering > > in LISP 1 doesn't matter, since both identifiers and locators are > routable > So, if you do have an alternative locator for the identifier, then > tunnel, else, forward directly > > similar in LISP 1.5 > > In LISP 2 and 3 the issue you are considering needs to be > considered imho > > probably it will induce additional latency, since you probably want > to check if the dest address is an identifier. > > in LISP 3 it depends wheter you are using the push or pull model > > if you have all the identifier to locator database available, then > you can check on it to verify if the destination is a identifier > and which are the locators > > if you don't have it, well, then you need to make a query and find > out, which will take additional delay You are right non Marcelo. I think taking the high-road by doing a LISP-push model gives you the best of all worlds. We still can incrementally deploy tunneling and by augmenting LISP-CAs and LISP- peering routers we can get EID-to-RLOC integrity, DOS-protection, and non-routable IDs. Mark Handley and I are working on a proposal. Give us some time to get it written down. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 02:33:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG5o-0003K3-0o; Mon, 02 Apr 2007 02:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG5m-0003Ej-RV for ram@iab.org; Mon, 02 Apr 2007 02:32:38 -0400 Received: from ind-iport-1.cisco.com ([64.104.129.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYG5Z-0002Bs-8P for ram@iab.org; Mon, 02 Apr 2007 02:32:38 -0400 Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by ind-iport-1.cisco.com with ESMTP; 03 Apr 2007 01:00:13 +0530 X-IronPort-AV: i="4.14,359,1170613800"; d="scan'208"; a="77561687:sNHT54477548" Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l326WG8Q023329; Mon, 2 Apr 2007 14:32:16 +0800 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 l326W5jc001763; Mon, 2 Apr 2007 06:32:11 GMT 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); Mon, 2 Apr 2007 14:31:43 +0800 Received: from emakko.cisco.com ([64.104.9.16]) by xfe-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 14:31:43 +0800 Received: from mstenber by emakko.cisco.com with local (Exim 4.62) (envelope-from ) id 1HYG38-0002tY-5z; Mon, 02 Apr 2007 15:29:54 +0900 From: Markus Stenberg To: Eliot Lear Subject: Re: [RAM] Incremental Deployment of LISP Organization: cisco Systems, Inc. References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <877isva4a0.fsf@emakko.cisco.com> <461097E5.6090307@cisco.com> Date: Mon, 02 Apr 2007 15:29:54 +0900 In-Reply-To: <461097E5.6090307@cisco.com> (Eliot Lear's message of "Mon, 02 Apr 2007 07:43:01 +0200") Message-ID: <87slbj8f19.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: 02 Apr 2007 06:31:43.0163 (UTC) FILETIME=[944150B0:01C774F0] Authentication-Results: hkg-dkim-1; header.From=mstenber@cisco.com; dkim=neutral ( ssp=~; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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 Eliot Lear writes: > Markus Stenberg wrote: >> I don't think anyone _has_ working push model that scales. DNS is pull; DHT >> is pull; BGP is push (but doesn't scale too well). > DNS demonstrates that the difference between push and pull isn't so > far as one might think. Consider the case when a primary server for a > zone sends out a notify for a zone. Is that push or pull? I'm not > worried about push or pull. I believe we can crack this nut, if the > rest of LISP works out well. What is the rest of LISP? A method for tunnelling packets? I think the wheel's fairly round already on that front. For me, on LISP front, the worrying part is that the early parts seem mostly useless (yay, we have _extra_ state all over, but no concrete gain, as global routing state just bloats more), and the hypothetical later parts (which haven't been specified too exactly) require _everyone_ you chat with to be LISP-enabled or they're also not very useful. Is the assumption that the routers all over suddenly one day turn LISP-enabled so someone will bother using actually (normally) non-routable EIDs? I think LISP 1.5+ is about as deployable as NIMROD+MPLS :-> (and less so than IPv6) >> Authenticating 'push' traffic even for current prefix updates is a hard >> problem [1]; > I really can't stress this enough that has to be a different problem, > or the game is really over. For one, you do not need to sign each > prefix separately. An authority needs to sign an update which may > contain many mappings. Second, the number of updates required in a > period of time has to be considerably smaller - BY SEVERAL ORDERS OF > MAGNITUDE - or we would have failed in our primary engineering > objective of better scaling the routing system. I think you missed my point; if you want the updates to be signed near source of the change (i.e. by someone trusted by the owner of the prefix, and therefore 'near' them in some trust hierarchy or whatever trust model you envision for this), you cannot aggregate them. Certainly, for just bulking the updates, you can just authenticate/encrypt/whatever them between two routers but there isn't significant gain to be seen there (your can only trust that yes, your neighbor received the data from somewhere). Anyway, I can see the number of prefixes dropping by one or two orders of magnitude at most by this effort, if that; just doing the geographical routing for continually expanding internet _will_ require fairly large locator-space routing table for the RIDs. > So, start by thinking about updates no more than once an hour and work > that are signed by an authority. In such a circumstance you can even > use a combination of push and pull, where SPs pull and then push to > their customers, or customers themselves pull from SPs who are pushed > updates. Either will scale, and most of the technology exists for > both. 'signed by an authority', which is that? From your earlier part of your comment, I assume you have some sort of central 'Internet Routing Authority' in mind, as otherwise you cannot have signed updates that can be bulked (because each router/AS will have their own set of key material, which they won't be keen to share). I like the IRA abbreviation too, maybe it could be new department of DHS ;-) More seriously though, if you assume you can really reduce the number of prefixes by order(s) of magnitude, I suppose you'd want to go for multi-level location mechanism, or otherwise allow for propagation time of hours on changes to the RID-space? For that, even current BGP would work. What my comment was aimed at was the more general locator-id, or RID+EID lookup, in which you CANNOT keep the amount of data down, and you will wind up with insane amount of data you will need to NOT move (i.e. have it be only on-demand, or pull), or the game is lost.. Certainly some points in the middle (e.g. SPs for example) can cache the pulled data, but essentially push isn't viable for the RID+EID case. I don't see RID-only stuff as interesting, because I'd say the currently existing technologies work on that front; however, for the EID+RID, I'm not so sure about the DNS (or especially the DHT). And my doubts are mostly in the trust/threat models, not in the actual scalability. DNS-based solution would most likely scale; however, it would be vulnerable to number of attacks. And no, DNSSec doesn't answer most of those problems - DNSSec poses more questions than it provides answers if you are looking for really sensible trust model for your effort. Cheers, -Markus _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 02:37:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG9v-0006AU-QP; Mon, 02 Apr 2007 02:36:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYG9u-00063l-5H for ram@iab.org; Mon, 02 Apr 2007 02:36:54 -0400 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 1HYG9s-0003Fn-SB for ram@iab.org; Mon, 02 Apr 2007 02:36:54 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 01 Apr 2007 23:36:51 -0700 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 l326aqKU022611; Sun, 1 Apr 2007 23:36:52 -0700 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 l326aqMF022669; Mon, 2 Apr 2007 06:36:52 GMT 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); Sun, 1 Apr 2007 23:36:52 -0700 Received: from [192.168.0.4] ([10.21.153.64]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 1 Apr 2007 23:36:51 -0700 In-Reply-To: <87slbj8f19.fsf@emakko.cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <877isva4a0.fsf@emakko.cisco.com> <461097E5.6090307@cisco.com> <87slbj8f19.fsf@emakko.cisco.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] Incremental Deployment of LISP Date: Sun, 1 Apr 2007 23:36:55 -0700 To: Markus Stenberg X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 06:36:51.0628 (UTC) FILETIME=[4C1D56C0:01C774F1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=443; t=1175495812; x=1176359812; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=mCbawVFtNt5/ZSRm83sAT0FaX48iKHwJ4HjjAEmZZnA=; b=oNOS/6nIsofvHh6YivAhUSj+zKnfOWXxY5X13/KS+7SPoyZETYOVJR7WfkurNsPu2ewFJnA8 skcOAKUWdFTP1EVo6LkDU2zgrSPVYE7gf/tBHZncNHVigN2+FfS/B6nX; 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: 68c8cc8a64a9d0402e43b8eee9fc4199 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 think LISP 1.5+ is about as deployable as NIMROD+MPLS :-> (and > less so > than IPv6) We could deploy LISP today on the MBGP topology. That would be an example of LISP 1.5, that is AFI=ipv4,SAFI=multicast. And if you set up a static GRE tunnel topology, either doing static EID-prefix configuration or distributing it via BGP on a completely different (much smaller) AS topology, that would be another example. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 04:34:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYHxl-0006WV-5b; Mon, 02 Apr 2007 04:32:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYHxj-0006Vc-71 for ram@iab.org; Mon, 02 Apr 2007 04:32:27 -0400 Received: from mtagate5.uk.ibm.com ([195.212.29.138]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYHxh-0001Yr-Q2 for ram@iab.org; Mon, 02 Apr 2007 04:32:27 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate5.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l328WOVM090936 for ; Mon, 2 Apr 2007 08:32:24 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l328WNep2678958 for ; Mon, 2 Apr 2007 09:32:24 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l328WMEg032279 for ; Mon, 2 Apr 2007 09:32:23 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l328WMi8032260; Mon, 2 Apr 2007 09:32:22 +0100 Received: from [9.146.220.138] (sig-9-146-220-138.de.ibm.com [9.146.220.138]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA334968; Mon, 2 Apr 2007 10:32:21 +0200 Message-ID: <4610BF94.7090508@zurich.ibm.com> Date: Mon, 02 Apr 2007 10:32:20 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Re: ICMP error dependency in LISP References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> In-Reply-To: <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Margaret Wasserman , 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-03-31 10:13, Dino Farinacci wrote: ... > The Internet is best-effort, we are not trying to make datagram delivery > more reliable. If a EID mapping has multiple locators and the ETR > indicates the priority of each locator is the same, the ITR can > load-split traffic among the locators. That raises the spectre of out-of-order delivery, which can be very painful for the transport layer. > >> d) some poor firewall or ACL filters out the ICMP message at the ICMP >> originator's domain, in transit, or at the recipient's domain? > > The protocol needs feedback. If you choose UDP to return the mapping or > error message, those could get filtered as well. There is no magic here, > you have to fix the filters. Well, I have to ask the same question I recently asked about shim6 error messages: will lost ICMP packets break the protocol? If yes, then I think that signalling in-band (i.e. in packets that are part of the target session) is much preferable. "Fix the filters" isn't a deployable feature of LISP, IMHO, because different people control the filters. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 04:35:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYI0Q-0001pV-Gb; Mon, 02 Apr 2007 04:35:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYI0P-0001mg-0y for ram@iab.org; Mon, 02 Apr 2007 04:35:13 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYI0L-00024m-NN for ram@iab.org; Mon, 02 Apr 2007 04:35:13 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 10:35:08 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l328Z7qL012119 for ; Mon, 2 Apr 2007 10:35:07 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp572.cisco.com [10.61.66.60]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l328Z4lZ022596 for ; Mon, 2 Apr 2007 08:35:06 GMT Message-ID: <4610C037.2020708@cisco.com> Date: Mon, 02 Apr 2007 10:35:03 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Incremental Deployment of LISP Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=880; t=1175502907; x=1176366907; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=AX9UqFrPGAFOhujFJjwdbV1hvtfPxeXlA5BsmmX2cpE=; b=Lm0MWPBrJbwwL9w6rrgzHK7gZp+BC5oV9jPXl2UZ9FOmn5FcMOPr7d5W2K6Y5Kn8JaSo/Zm1 rHIsrWThYZcfraCOOMV3BE2eFVdTqNLaBVk/Mp4DDNnKN+D+Hs1MFF8B; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 [resending to RAM] Markus Stenberg wrote: > 'signed by an authority', which is that? This is the right question to ask. There can be several answers but they all will have the flavor of being a small number of entities distributing to a large number of receivers, probably through at least one additional distribution level. IMHO we should engineer for the ability to process these updates end to end in about a minute, but that you REALLY don't want to update more than once an hour. Consider the following possibilities for authorities: * IANA - the ultimate source of address space * RIRs - the delegated sources of address space * A new "Locator Registry"(*) - a new delegated source of PI addresses Each of these has pluses and minuses. I suspect that if we advance LISP further an additional internet draft is in order. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 04:39:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYI4T-0006u4-HC; Mon, 02 Apr 2007 04:39:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYI4S-0006rd-KV for ram@iab.org; Mon, 02 Apr 2007 04:39:24 -0400 Received: from mtagate2.uk.ibm.com ([195.212.29.135]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYI4R-00041r-6x for ram@iab.org; Mon, 02 Apr 2007 04:39:24 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l328dLIG042554 for ; Mon, 2 Apr 2007 08:39:21 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.3) with ESMTP id l328dKls2793654 for ; Mon, 2 Apr 2007 09:39:20 +0100 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 l328dKTv024365 for ; Mon, 2 Apr 2007 09:39:20 +0100 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 l328dKU3024349; Mon, 2 Apr 2007 09:39:20 +0100 Received: from [9.146.220.138] (sig-9-146-220-138.de.ibm.com [9.146.220.138]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA25896; Mon, 2 Apr 2007 10:39:18 +0200 Message-ID: <4610C136.2010401@zurich.ibm.com> Date: Mon, 02 Apr 2007 10:39:18 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Meyer Subject: Re: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP References: <20070330132029.GA23969@nic.fr> <39C363776A4E8C4A94691D2BD9D1C9A10177485F@XCH-NW-7V2.nw.nos.boeing.com> <20070330161202.GA29763@1-4-5.net> In-Reply-To: <20070330161202.GA29763@1-4-5.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Cc: "Templin, Fred L" , 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-03-30 18:12, David Meyer wrote: > On Fri, Mar 30, 2007 at 08:36:21AM -0700, Templin, Fred L wrote: >> I think the subject of this message hits the mark, and >> maybe there is some confusion about what needs to go >> in the global DNS. Only FQDNs with locators for egress >> tunnel routers need to go in the global DNS, and that >> is not a lot more than what we are asking the global >> DNS to carry today. >> >> FQDNs for the services themselves are not resolved in >> the global DNS; they are resolved in site-specific name >> services instead. > > I've said this once already, however, it might be > instructive to look at the other existing instance where > this has been tried, i.e., carrier/infrastructure > ENUM. There are some lessons, both technical and > non-technical to be learned there. See e.g. > http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-infrastructure-enum.html It would seem a little strange to me to actively advocate walled-garden namespaces as part of the way to make the Internet scale up transparently. I don't want example.com to resolve to some local SP or corporate notion of who should be providing the services branded as 'example'. Brian Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 05:15: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 1HYIcI-0004lV-DJ; Mon, 02 Apr 2007 05:14:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIcH-0004lL-JD for ram@iab.org; Mon, 02 Apr 2007 05:14:21 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYIcF-0003rp-4u for ram@iab.org; Mon, 02 Apr 2007 05:14:21 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l329EG7o109344 for ; Mon, 2 Apr 2007 09:14:16 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.3) with ESMTP id l329EGZT2171076 for ; Mon, 2 Apr 2007 11:14:16 +0200 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 l329EFvV021554 for ; Mon, 2 Apr 2007 11:14:15 +0200 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 l329EFYR021546 for ; Mon, 2 Apr 2007 11:14:15 +0200 Received: from [9.146.220.138] (sig-9-146-220-138.de.ibm.com [9.146.220.138]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA339954 for ; Mon, 2 Apr 2007 11:14:14 +0200 Message-ID: <4610C965.8010208@zurich.ibm.com> Date: Mon, 02 Apr 2007 11:14:13 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: ram@iab.org Subject: Thousands of large PI customers [Re: [RAM] Incremental Deployment of LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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-03-30 19:49, Fleischman, Eric wrote: ... > ... For example, my coworkers > and I have been telling various IETF mail lists for the past decade that > it is non-negotiable that we will solely accept PI addresses whether or > not the IETF permits a PA-PI address distinction to exist or not. The > world's other largest companies and governments are almost certainly > going to make similar demands. I believe this simply doesn't matter from a DFZ scaling point of view. A few thousand large PI customers is surely not an issue. What matters is the potential for 10 million PI customers, unless we provide an alternative approach for them. (That was the starting point for shim6 - it isn't aimed at Boeing or IBM.) LISP seems to lead to a world with 10M PI customers, and therefore a PI to PA map with 10M entries. On 2007-04-01 05:14, Ross Callon wrote: ... > Perhaps we need a terminology distinction between "a PI address > which is in the global routing table -- just like now", and "a PI > address that is not in the global routing table, but needs to be > mapped to a PA address". Perhaps "Routable PI" (RPI) and > "Nonroutable PI" (NPI)? But we have that. ULAs are non-routable PI. That's exactly what they were designed for. RFC1918 addresses are really just defective ULAs, given the shortage of IPv4 space. Puzzle me this. What is the difference between (a) using LISP between two PI sites over some piece of ISP locator space and (b) a PPVPN between those two sites? Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 05:19:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIhR-0008I4-Jm; Mon, 02 Apr 2007 05:19:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYIhP-0008Hw-Tf for ram@iab.org; Mon, 02 Apr 2007 05:19:39 -0400 Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYIhO-0004gd-Gj for ram@iab.org; Mon, 02 Apr 2007 05:19:39 -0400 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 l329JbTC120054 for ; Mon, 2 Apr 2007 09:19:37 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l329JauH2134254 for ; Mon, 2 Apr 2007 11:19:36 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l329Ja9x011701 for ; Mon, 2 Apr 2007 11:19:36 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l329Jadc011691; Mon, 2 Apr 2007 11:19:36 +0200 Received: from [9.146.220.138] (sig-9-146-220-138.de.ibm.com [9.146.220.138]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA357430; Mon, 2 Apr 2007 11:19:35 +0200 Message-ID: <4610CAA7.1090900@zurich.ibm.com> Date: Mon, 02 Apr 2007 11:19:35 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [RAM] Incremental Deployment of LISP References: <4610C037.2020708@cisco.com> In-Reply-To: <4610C037.2020708@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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-04-02 10:35, Eliot Lear wrote: > [resending to RAM] > > Markus Stenberg wrote: >> 'signed by an authority', which is that? > > This is the right question to ask. There can be several answers but > they all will have the flavor of being a small number of entities > distributing to a large number of receivers, probably through at least > one additional distribution level. IMHO we should engineer for the > ability to process these updates end to end in about a minute, but that > you REALLY don't want to update more than once an hour. > > Consider the following possibilities for authorities: > > * IANA - the ultimate source of address space > * RIRs - the delegated sources of address space > * A new "Locator Registry"(*) - a new delegated source of PI addresses ULAs are self-assigned PI, so the authority is the site using them. An interesting security property... Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 05:57:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJG5-0007jK-8Q; Mon, 02 Apr 2007 05:55:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJG4-0007jC-5m for ram@iab.org; Mon, 02 Apr 2007 05:55:28 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJG2-0001me-Tn for ram@iab.org; Mon, 02 Apr 2007 05:55:28 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 11:55:22 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l329tMal008122; Mon, 2 Apr 2007 11:55:22 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp572.cisco.com [10.61.66.60]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l329tJlZ020071; Mon, 2 Apr 2007 09:55:19 GMT Message-ID: <4610D306.6060008@cisco.com> Date: Mon, 02 Apr 2007 11:55:18 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: [RAM] Incremental Deployment of LISP References: <4610C037.2020708@cisco.com> <4610CAA7.1090900@zurich.ibm.com> In-Reply-To: <4610CAA7.1090900@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=215; t=1175507722; x=1176371722; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=9YyICZTIx6CW8ziL4xk8aNJahxIAA7bhU9SN2XKLv/0=; b=DmpbzZV0fj5d0hM7X2PZuCPTllalm4pKVjqTRxRpyVPAUtoEfHzhgXe9/BcWnVTwxq+ddlEM H7/qaIHRd8nKiorryqkla9Uh9CDP8ySKNVB+CxyJimBAX+RjHeiC4V8M; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Brian E Carpenter wrote: > ULAs are self-assigned PI, so the authority is the site using them. > An interesting security property... > It's not secure at all. I can pick the same ULA you are using. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 06:01:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJM8-0004oA-Uv; Mon, 02 Apr 2007 06:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYJM7-0004nG-O2 for ram@iab.org; Mon, 02 Apr 2007 06:01:43 -0400 Received: from [203.167.203.10] (helo=enso.acheron.indranet.co.nz) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYJM4-0002jg-34 for ram@iab.org; Mon, 02 Apr 2007 06:01:43 -0400 Received: from [127.0.0.1] (IDENT:root@enso.acheron.indranet.co.nz [192.168.1.1]) by enso.acheron.indranet.co.nz (8.9.3-20030919/8.9.3) with ESMTP id WAA01157; Mon, 2 Apr 2007 22:01:03 +1200 In-Reply-To: <4610D306.6060008@cisco.com> References: <4610C037.2020708@cisco.com> <4610CAA7.1090900@zurich.ibm.com> <4610D306.6060008@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <683E3558-6191-474F-81AD-08515E962BFF@indranet.co.nz> Content-Transfer-Encoding: 7bit From: Andrew McGregor Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 22:00:59 +1200 To: Eliot Lear X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 02/04/2007, at 9:55 PM, Eliot Lear wrote: > Brian E Carpenter wrote: >> ULAs are self-assigned PI, so the authority is the site using them. >> An interesting security property... >> > > It's not secure at all. I can pick the same ULA you are using. > > Eliot Which is the strength of HIP.... it doesn't matter unless you have picked the same private key as well, which is astronomically unlikely. Andrew _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 07:12:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKQk-0000hG-E4; Mon, 02 Apr 2007 07:10:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYKQj-0000hA-RY for ram@iab.org; Mon, 02 Apr 2007 07:10:33 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYKQi-0007To-JO for ram@iab.org; Mon, 02 Apr 2007 07:10:33 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AF7F819869D; Mon, 2 Apr 2007 14:10:31 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 598CE19869B; Mon, 2 Apr 2007 14:10:31 +0300 (EEST) Message-ID: <4610E4A7.1080604@piuha.net> Date: Mon, 02 Apr 2007 14:10:31 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ram@iab.org 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: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Subject: [RAM] id-locator separation -- next steps, interims, etc. 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 a heads-up that we've been talking with the RRG Chairs, RTG ADs, and IAB about how to organize the identifier-locator separation effort across the IRTF and IETF going forward. As soon as we are done with this, we will propose some next steps, including whether or not we will organize a special meeting on this topic before the next general IETF meeting. Jari and Mark _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 08:03:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLFV-00050U-6v; Mon, 02 Apr 2007 08:03:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLFT-0004vd-KK for ram@iab.org; Mon, 02 Apr 2007 08:02:59 -0400 Received: from smtp.aaisp.net.uk ([2001:8b0:0:81::51bb:5134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYLFS-0004Gl-8u for ram@iab.org; Mon, 02 Apr 2007 08:02:59 -0400 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 1HYLF5-00044j-AW for ram@iab.org; Mon, 02 Apr 2007 13:02:35 +0100 Message-ID: <4610F11C.4030005@dial.pipex.com> Date: Mon, 02 Apr 2007 13:03:40 +0100 From: Elwyn Davies User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: RAM Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -2.4 (--) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [RAM] EATing into the core bandwidth 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 mind was obviously too into taxes this Monday morning (the end of the UK tax year soon)... Just a reminder when we are adding up the costs and benefits of the various approaches, such as LISP, that some of them impose EAT (Encapsulation Added Tax). Calculations based on the distribution of packet sizes in the current network indicate that LISP would impose an extra average overhead on IPv4 traffic of around 5 to 7% in bits to be carried. The exact figure depends on the distribution you use but is heavily biassed by the large number of TCP ACK packets for which EAT is around 45%. If the same distributions are used for IPv6 traffic the overhead rises to 7 to 9% assuming a similar sort of LISP header. Whilst these are not enormous figures, given the organic growth in traffic, they are truly overhead that is applicable to all future traffic and that gains no extra revenue. This might be a significant factor in an increasingly commoditised backbone network. /Elwyn _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 08:48:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLvG-0001Yc-Ir; Mon, 02 Apr 2007 08:46:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYLvF-0001Pq-5q for ram@iab.org; Mon, 02 Apr 2007 08:46:09 -0400 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYLvD-0008C3-Ij for ram@iab.org; Mon, 02 Apr 2007 08:46:08 -0400 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 l32Ck6g9117458 for ; Mon, 2 Apr 2007 12:46:06 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.3) with ESMTP id l32Ck6N32359502 for ; Mon, 2 Apr 2007 13:46:06 +0100 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 l32Ck5EJ005703 for ; Mon, 2 Apr 2007 13:46:05 +0100 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 l32Ck5kB005684; Mon, 2 Apr 2007 13:46:05 +0100 Received: from [9.146.220.138] (sig-9-146-220-138.de.ibm.com [9.146.220.138]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA215952; Mon, 2 Apr 2007 14:46:04 +0200 Message-ID: <4610FB0A.2070706@zurich.ibm.com> Date: Mon, 02 Apr 2007 14:46:02 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eliot Lear Subject: Re: [RAM] Incremental Deployment of LISP References: <4610C037.2020708@cisco.com> <4610CAA7.1090900@zurich.ibm.com> <4610D306.6060008@cisco.com> In-Reply-To: <4610D306.6060008@cisco.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@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-04-02 11:55, Eliot Lear wrote: > Brian E Carpenter wrote: >> ULAs are self-assigned PI, so the authority is the site using them. >> An interesting security property... >> > > It's not secure at all. I can pick the same ULA you are using. Sure. That's why they must be blocked by border routers. But if they were registered automatically in a FCFS registry, we could find a way round this (and the registry would become the authority). Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 09:32:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMdL-0000jQ-ID; Mon, 02 Apr 2007 09:31:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMdL-0000hF-4Y for ram@iab.org; Mon, 02 Apr 2007 09:31:43 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMdI-00051c-BF for ram@iab.org; Mon, 02 Apr 2007 09:31:43 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id C8BB5872C1; Mon, 2 Apr 2007 09:31:39 -0400 (EDT) To: ram@iab.org Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deployment of LISP] Message-Id: <20070402133139.C8BB5872C1@mercury.lcs.mit.edu> Date: Mon, 2 Apr 2007 09:31:39 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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: Brian E Carpenter > What is the difference between (a) using LISP between two PI sites over > some piece of ISP locator space and (b) a PPVPN between those two sites? If those two sites are only talking to each other, then at a high level (ignoring protocol details), not much. The point, of course, is that LISP is supposed to allow those two sites to talk, not just to each other, but to the rest of the network - something you couldn't accomplish with PPVPN's without N^2 of them. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 09:42:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMnT-000861-6y; Mon, 02 Apr 2007 09:42:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYMnR-00085q-HL for ram@iab.org; Mon, 02 Apr 2007 09:42:09 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYMnQ-000703-4o for ram@iab.org; Mon, 02 Apr 2007 09:42:09 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 02 Apr 2007 06:42:08 -0700 X-IronPort-AV: i="4.14,361,1170662400"; d="scan'208"; a="680261805:sNHT36456448" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l32Dg7J83715; Mon, 2 Apr 2007 06:42:07 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704021342.l32Dg7J83715@merlot.juniper.net> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deployment of LISP] In-Reply-To: Your message of "Mon, 02 Apr 2007 09:31:39 EDT." <20070402133139.C8BB5872C1@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <93576.1175521327.1@juniper.net> Date: Mon, 02 Apr 2007 06:42:07 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Noel, > > From: Brian E Carpenter > > > What is the difference between (a) using LISP between two PI sites over > > some piece of ISP locator space and (b) a PPVPN between those two sites ? > > If those two sites are only talking to each other, then at a high level > (ignoring protocol details), not much. > > The point, of course, is that LISP is supposed to allow those two sites to > talk, not just to each other, but to the rest of the network - something you > couldn't accomplish with PPVPN's without N^2 of them. "N^2 of them". What are these "N^2" ? Yakov. > > Noel > > _______________________________________________ > 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 Apr 02 10:21:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNNT-0000U6-6B; Mon, 02 Apr 2007 10:19:23 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNNR-0000Tz-Uf for ram@iab.org; Mon, 02 Apr 2007 10:19:21 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYNNQ-0002Sf-JL for ram@iab.org; Mon, 02 Apr 2007 10:19:21 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D929C86B00; Mon, 2 Apr 2007 10:19:15 -0400 (EDT) To: ram@iab.org Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deployment of LISP] Message-Id: <20070402141915.D929C86B00@mercury.lcs.mit.edu> Date: Mon, 2 Apr 2007 10:19:15 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: Yakov Rekhter >>> What is the difference between (a) using LISP between two PI sites >>> over some piece of ISP locator space and (b) a PPVPN between those >>> two sites >> If those two sites are only talking to each other, then at a high level >> .. not much. ... LISP is supposed to allow those two sites to talk, >> not just to each other, but to the rest of the network - something you >> couldn't accomplish with PPVPN's without N^2 of them. > "N^2 of them". What are these "N^2" ? I was assuming the common case of PPVPN's where the interface seen by the customers is some sort of Layer-2 point-point link - e.g. ATM/MPLS. Then, if you have N sites, which all wanted to be able to talk amongst each other, you'd need N^2 connections - unless you wanted to accept the extra delay/etc of multi-hop paths, plus you'd need to run some sort of routing protocol. Sure, there are other kinds of PPVPN, but in all of them, the keyword in that acronym "PPVPN" is still "Private" - i.e. talking to a limited set of other entities. LISP is intended for use by a large, non-homogenous set of entities - and that's what I was trying to point out as being the key difference between the two cases Brian listed (in addition to the specific point about point-point PPVPN's). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 10:27:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNVJ-0005E1-GK; Mon, 02 Apr 2007 10:27:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNVI-0005Dw-0M for ram@iab.org; Mon, 02 Apr 2007 10:27:28 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNVG-0007tL-NN for ram@iab.org; Mon, 02 Apr 2007 10:27:27 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 02 Apr 2007 07:27:26 -0700 X-IronPort-AV: i="4.14,361,1170662400"; d="scan'208"; a="701051203:sNHT136673500" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l32ERPJ92212; Mon, 2 Apr 2007 07:27:26 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704021427.l32ERPJ92212@merlot.juniper.net> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deployment of LISP] In-Reply-To: Your message of "Mon, 02 Apr 2007 10:19:15 EDT." <20070402141915.D929C86B00@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <94810.1175524045.1@juniper.net> Date: Mon, 02 Apr 2007 07:27:26 -0700 From: Yakov Rekhter 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 Noel, > > From: Yakov Rekhter > > >>> What is the difference between (a) using LISP between two PI sites > >>> over some piece of ISP locator space and (b) a PPVPN between those > >>> two sites > > >> If those two sites are only talking to each other, then at a high leve l > >> .. not much. ... LISP is supposed to allow those two sites to talk, > >> not just to each other, but to the rest of the network - something you > >> couldn't accomplish with PPVPN's without N^2 of them. > > > "N^2 of them". What are these "N^2" ? > > I was assuming the common case of PPVPN's where the interface seen by the > customers is some sort of Layer-2 point-point link - e.g. ATM/MPLS. Then, if > you have N sites, which all wanted to be able to talk amongst each other, > you'd need N^2 connections - unless you wanted to accept the extra delay/etc > of multi-hop paths, plus you'd need to run some sort of routing protocol. Without going into a discussion on what is "the common case of PPVPNs", let me just point out that 2547 VPNs do *not* require "N^2 connections" (for more details see rfc4364). > Sure, there are other kinds of PPVPN, but in all of them, the keyword in that > acronym "PPVPN" is still "Private" - i.e. talking to a limited set of other > entities. LISP is intended for use by a large, non-homogenous set of entities > - and that's what I was trying to point out as being the key difference > between the two cases Brian listed (in addition to the specific point about > point-point PPVPN's). Let me point out that some service providers implement the Internet service as a 2547 VPN. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 10:32:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNZg-00073F-1k; Mon, 02 Apr 2007 10:32:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNZd-00070z-Sm for ram@iab.org; Mon, 02 Apr 2007 10:31:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNZb-0000gN-Ft for ram@iab.org; Mon, 02 Apr 2007 10:31:57 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 16:31:54 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32EVqSY002962; Mon, 2 Apr 2007 16:31:52 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32EVqlZ022109; Mon, 2 Apr 2007 14:31:52 GMT Received: from xmb-ams-331.cisco.com ([144.254.231.76]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 16:31:52 +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: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 16:31:46 +0200 Message-ID: <2C9EA52903BE104EB172E2DB1FD48D9D0248C74D@xmb-ams-331.emea.cisco.com> In-Reply-To: <200704021427.l32ERPJ92212@merlot.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Thread-Index: Acd1MzGtsFlRL99PTWi/X3OMpACSHwAAEfbw From: "Gunter Van de Velde \(gvandeve\)" To: "Yakov Rekhter" , "Noel Chiappa" X-OriginalArrivalTime: 02 Apr 2007 14:31:52.0330 (UTC) FILETIME=[A7DB56A0:01C77533] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2286; t=1175524312; x=1176388312; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=gvandeve@cisco.com; z=From:=20=22Gunter=20Van=20de=20Velde=20\(gvandeve\)=22=20 |Subject:=20RE=3A=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP]=20 |Sender:=20; bh=iZP3n/jw/hzKyX1kBMlQnfee5dV/SMDqMIas8GAG9Ds=; b=KrF3YTBqiMJeqihfs2zi2NgD8q/IiJOKf43Ql8WFtdxdzq3outxCX2PzxbVyJUjHBwOXDa7h RThIYSV5HMkvnr274c6i95Y8WxVQTojSeBLFCMQtWJZnS4ey+So8kkZe; Authentication-Results: ams-dkim-1; header.From=gvandeve@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 <> Let me point out that some service providers implement the Internet service as a 2547 VPN. <> Do they put all Internet routes in the 2547 VPN? G/ -----Original Message----- From: Yakov Rekhter [mailto:yakov@juniper.net]=20 Sent: Monday, April 02, 2007 4:27 PM To: Noel Chiappa Cc: ram@iab.org Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP]=20 Noel, > > From: Yakov Rekhter >=20 > >>> What is the difference between (a) using LISP between two PI sites > >>> over some piece of ISP locator space and (b) a PPVPN between those > >>> two sites >=20 > >> If those two sites are only talking to each other, then at a=20 > high leve l > >> .. not much. ... LISP is supposed to allow those two sites to talk, > >> not just to each other, but to the rest of the network - something you > >> couldn't accomplish with PPVPN's without N^2 of them. >=20 > > "N^2 of them". What are these "N^2" ? >=20 > I was assuming the common case of PPVPN's where the interface seen by=20 > the customers is some sort of Layer-2 point-point link - e.g.=20 > ATM/MPLS. Then, if you have N sites, which all wanted to be able to=20 > talk amongst each other, you'd need N^2 connections - unless you=20 > wanted to accept the extra delay/etc of multi-hop paths, plus you'd need to run some sort of routing protocol. Without going into a discussion on what is "the common case of PPVPNs", let me just point out that 2547 VPNs do *not* require "N^2 connections" (for more details see rfc4364). > Sure, there are other kinds of PPVPN, but in all of them, the keyword=20 > in that acronym "PPVPN" is still "Private" - i.e. talking to a limited > set of other entities. LISP is intended for use by a large,=20 > non-homogenous set of entities > - and that's what I was trying to point out as being the key=20 > difference between the two cases Brian listed (in addition to the=20 > specific point about point-point PPVPN's). Let me point out that some service providers implement the Internet service as a 2547 VPN. Yakov. _______________________________________________ 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 Apr 02 10:37:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNeH-0001BU-Fk; Mon, 02 Apr 2007 10:36:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNeG-0001BK-7R for ram@iab.org; Mon, 02 Apr 2007 10:36:44 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNeF-0001Rt-0A for ram@iab.org; Mon, 02 Apr 2007 10:36:44 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 02 Apr 2007 07:36:43 -0700 X-IronPort-AV: i="4.14,362,1170662400"; d="scan'208"; a="701055441:sNHT33107516" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l32EagJ93899; Mon, 2 Apr 2007 07:36:42 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704021436.l32EagJ93899@merlot.juniper.net> To: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <95275.1175524602.1@juniper.net> Date: Mon, 02 Apr 2007 07:36:42 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Rolan, > On Mar 31, 2007, at 8:14 PM, Ross Callon wrote: >>...But I have a default route, so I can always route the packet >>-- until it gets to the default free core of the Internet. [If the >>default route doesn't count as "a route", then I can never >>route the packet (unless it starts in the default free core of >>the Internet).] > > Multihomed endpoint networks don't typically take (or are offered) > default. Typically an ISP have three categories of customers: (1) those who receive just default, (2) those who receive routes for all of the ISP's customers, plus default (for customers attached to other ISPs), and (3) full set of routes. Multihomed customers may fall into any of the above three categories. Are you saying that multihomed customers typically fall into the third category ? Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 10:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNf3-0002rY-GR; Mon, 02 Apr 2007 10:37:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNf1-0002rS-UM for ram@iab.org; Mon, 02 Apr 2007 10:37:31 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNf0-0001Xm-Ew for ram@iab.org; Mon, 02 Apr 2007 10:37:31 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32ENM61034109; Mon, 2 Apr 2007 07:23:22 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 07:36:59 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 07:36:59 -0700 In-Reply-To: <460FE3D6.3040300@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 07:36:57 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Eliot, On Apr 1, 2007, at 9:54 AM, Eliot Lear wrote: >>> Lookups are a non-starter because of the lookup latency and what >>> you do with a packet on a cache miss >> I wonder if the folks who argued against moving from HOSTS.TXT to >> the DNS used the same rationale... :-) > Remember, with LISP we're talking about ROUTERS switching PACKETs > and not END HOSTS establishing a communication (be it UDP, TCP, > SCTP, or whatever). The routers won't need to switch packets until an end host tries to establish communication. > My concern is latency in establishing a connection when everything > is in a nominal state, particularly due to an off-the-box lookup. The normal state will be a lookup in local cache. Yes, the initial state will require an off-the-box lookup which has increased latency. The cost of this additional latency at communication initiation is what you pay for increased scalability, flexibility, and updatability. You only fetch what you need when you need it. Contrast this to the RADB model which requires all the mapping data to be propagated globally regardless of any usage patterns. How big is this table going to be (that is, how many end points will their be in the routing system)? Yes, you can propagate diffs, but you still have to propagate the initial table to do the diffs against. How long will that initial table download take? > Yes, you can do it with DNS, but that will produce unacceptable > latency. You make this assertion like it is axiomatic. What is your definition of acceptable? Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 10:47:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNns-00024r-AZ; Mon, 02 Apr 2007 10:46:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYNnq-00024I-KB for ram@iab.org; Mon, 02 Apr 2007 10:46:38 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYNnp-0002qO-7X for ram@iab.org; Mon, 02 Apr 2007 10:46:38 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l32EkHaQ028361; Mon, 2 Apr 2007 07:46:17 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l32EkDU7028360; Mon, 2 Apr 2007 07:46:13 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Mon, 2 Apr 2007 07:46:13 -0700 From: David Meyer To: Brian E Carpenter Subject: Re: [RAM] The DNS? Which DNS? (Was: Incremental Deployment of LISP Message-ID: <20070402144613.GB27937@1-4-5.net> References: <20070330132029.GA23969@nic.fr> <39C363776A4E8C4A94691D2BD9D1C9A10177485F@XCH-NW-7V2.nw.nos.boeing.com> <20070330161202.GA29763@1-4-5.net> <4610C136.2010401@zurich.ibm.com> Mime-Version: 1.0 In-Reply-To: <4610C136.2010401@zurich.ibm.com> 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: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Cc: "Templin, Fred L" , 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="===============0804324221==" Errors-To: ram-bounces@iab.org --===============0804324221== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="eAbsdosE1cNLO4uF" Content-Disposition: inline --eAbsdosE1cNLO4uF Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Apr 02, 2007 at 10:39:18AM +0200, Brian E Carpenter wrote: > On 2007-03-30 18:12, David Meyer wrote: > >On Fri, Mar 30, 2007 at 08:36:21AM -0700, Templin, Fred L wrote: > >>I think the subject of this message hits the mark, and > >>maybe there is some confusion about what needs to go > >>in the global DNS. Only FQDNs with locators for egress > >>tunnel routers need to go in the global DNS, and that > >>is not a lot more than what we are asking the global > >>DNS to carry today. > >> > >>FQDNs for the services themselves are not resolved in > >>the global DNS; they are resolved in site-specific name > >>services instead. > > > > I've said this once already, however, it might be > > instructive to look at the other existing instance where > > this has been tried, i.e., carrier/infrastructure > > ENUM. There are some lessons, both technical and > > non-technical to be learned there. See e.g. > > http://voipandenum.blogspot.com/2006/03/dallas-treaty-on-infrastructure= -enum.html >=20 > It would seem a little strange to me to actively advocate > walled-garden namespaces as part of the way to make the > Internet scale up transparently. I don't want example.com > to resolve to some local SP or corporate notion of who should > be providing the services branded as 'example'. To be a little more clear, the "example" was intended to illustrate the pitfalls of trying to create special purpose "disconnected" parts of the DNS (i.e., it doesn't work, because the new "apexes" will be a source of revenue/control for someone, ...).=20 That said, I agree with what you have said about consistency of response(s) from the DNS. --dmm --eAbsdosE1cNLO4uF Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGERc1ORgD1qCZ2KcRApYSAKCKzwWq8D3gTCtmfjbxmdQ5pvHI/QCgixVM ZDHKhmoQF8vywO2Sic+WZvo= =DdO2 -----END PGP SIGNATURE----- --eAbsdosE1cNLO4uF-- --===============0804324221== 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 --===============0804324221==-- From ram-bounces@iab.org Mon Apr 02 11:11:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOB6-0003aY-Ee; Mon, 02 Apr 2007 11:10:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOB4-0003Yv-Up for ram@iab.org; Mon, 02 Apr 2007 11:10:39 -0400 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 1HYOB1-00067Q-N8 for ram@iab.org; Mon, 02 Apr 2007 11:10:38 -0400 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 l32FAW0B017487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 10:10:33 -0500 (CDT) 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 l32FAVSG008771; Mon, 2 Apr 2007 08:10:31 -0700 (PDT) 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 l32FAMhI008285; Mon, 2 Apr 2007 08:10:27 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 08:10:26 -0700 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: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 08:10:26 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EAB@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <200704021342.l32Dg7J83715@merlot.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Thread-Index: Acd1LMnus/OsHcCDR5+prGaxNo6+eAACyfDw References: Your message of "Mon, 02 Apr 2007 09:31:39 EDT."<20070402133139.C8BB5872C1@mercury.lcs.mit.edu> <200704021342.l32Dg7J83715@merlot.juniper.net> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 02 Apr 2007 15:10:26.0917 (UTC) FILETIME=[0B754950:01C77539] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: Yakov Rekhter [mailto:yakov@juniper.net]=20 >"N^2 of them". What are these "N^2" ? If the ISPs place the tunnel end points at their customers' premises, like the PE-CE boundary of L3VPN, then there are indeed N**2 tunnels and the approach will not scale, IMO.=20 If the ISPs place the tunnel end points at their own boundary with other ISPs, and aggregate the traffic of their customers to that boundary, then the number is a function of the number of ISPs -- ISP**2. However, I expect the ISPs to form confederations to provide differentiated service distinctions to support L3VPN services, in addition to supporting LISP (i.e., many different services will be provided). In this case, the number of tunnels is a function of the number of ISP confederations, which is Confederation**2. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:19:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOJe-00046U-2e; Mon, 02 Apr 2007 11:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOJc-00046N-Mb for ram@iab.org; Mon, 02 Apr 2007 11:19:28 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOJb-0007NX-EU for ram@iab.org; Mon, 02 Apr 2007 11:19:28 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 08:19:27 -0700 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 l32FJQG8009428 for ; Mon, 2 Apr 2007 08:19:26 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32FJQwn028142 for ; Mon, 2 Apr 2007 15:19:26 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <200704021436.l32EagJ93899@merlot.juniper.net> References: <200704021436.l32EagJ93899@merlot.juniper.net> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <924A2FFC-A308-439C-A761-31288224A34E@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 08:19:47 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=485; t=1175527166; x=1176391166; 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]=20Incremental=20Deployment=20of=20LISP=20 |Sender:=20; bh=SLoAAgJ68rzLi+Bqr3rSVFipnL/N2DROUMp8b3NFs0c=; b=O73wu4lwroU499WGmzYL81w/UvYatzGhiKsnh9loCGDC4Wa/4Xt8BX4xi8pSlmxgkXhpPskz HinBDclhHITwTCMcE0Kj2v02Yz3HGXalyzUFiO++0KEAUz10KAeMFj6y; 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: cf4fa59384e76e63313391b70cd0dd25 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 Apr 2, 2007, at 7:36 AM, Yakov Rekhter wrote: > Are you saying that multihomed customers typically fall into > the third category ? In my experience, yes. There are other variations, naturally, but it seems to be increasingly common. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:31:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOTk-0003dN-PX; Mon, 02 Apr 2007 11:29:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOTk-0003cx-4a for ram@iab.org; Mon, 02 Apr 2007 11:29:56 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOTi-0008IT-S5 for ram@iab.org; Mon, 02 Apr 2007 11:29:56 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32FTrNm010329 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 08:29:54 -0700 (PDT) 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 l32FTqYH008060; Mon, 2 Apr 2007 08:29:52 -0700 (PDT) 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 l32FTor6007967; Mon, 2 Apr 2007 08:29:51 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 08:29:49 -0700 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: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 08:29:49 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4610C965.8010208@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Thread-Index: Acd1B2M3hCMLX/DUTFub+vC+jc7HrwAMlopA References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 02 Apr 2007 15:29:49.0900 (UTC) FILETIME=[C0A668C0:01C7753B] 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 >From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 >LISP seems to lead to a world with 10M PI customers, and therefore a=20 >PI to PA map with 10M entries. I understand your concern, but LISP need not be deployed in this fashion. If the tunnel boundaries are deep within the ISP, perhaps at their borders with other ISPs, then they will aggregate the end users they support, much like the current system. Unlike the current system, both the ISP and the end user are provided flexibility that don't currently exist. With LISP, ISPs are presented huge opportunities for market differentiation and end users are presented an opportunity to address their infrastructures as they see fit. Issues that are currently the concern of the entire Internet because everyone impacts everyone else in the current model now become business issues negotiated between the local ISP and the end user because the ISP (and their confederations) now become mini-Internets, modularizing the true Internet.=20 LISP needn't be an all-or-nothing solution. I envision strong market pressures preserving L2VPN and L3VPN, in addition to supporting LISP as the generic service for most end users. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:33:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOWd-0004C1-6r; Mon, 02 Apr 2007 11:32:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOWZ-0004Aa-Uu for ram@iab.org; Mon, 02 Apr 2007 11:32:51 -0400 Received: from smtp-1.dynsipr.ucl.ac.be ([130.104.4.1] helo=smtp1.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOWV-000058-Hf for ram@iab.org; Mon, 02 Apr 2007 11:32:51 -0400 Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id 2C4092C5B2; Mon, 2 Apr 2007 17:32:35 +0200 (CEST) Received: from [130.104.229.95] (unknown [130.104.229.95]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Mon, 2 Apr 2007 17:32:35 +0200 (CEST) Message-ID: <4611220A.6030401@info.ucl.ac.be> Date: Mon, 02 Apr 2007 17:32:26 +0200 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: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP References: <200704021436.l32EagJ93899@merlot.juniper.net> <924A2FFC-A308-439C-A761-31288224A34E@cisco.com> In-Reply-To: <924A2FFC-A308-439C-A761-31288224A34E@cisco.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.5, requis 5, autolearn=not spam, BAYES_00 -2.60, RCVD_AUTH_OK -20.00, SARE_FROM_SPAM_WORD3 0.10, SPF_HELO_PASS -0.00) X-SGSI-From: bonaventure@info.ucl.ac.be X-SGSI-Spam-Status: No 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 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 Roland, > > On Apr 2, 2007, at 7:36 AM, Yakov Rekhter wrote: > >> Are you saying that multihomed customers typically fall into >> the third category ? > > > In my experience, yes. There are other variations, naturally, but it > seems to be increasingly common. When multihomed customer request full BGP routing tables, this is often because they expect that BGP information (i.e. AS-Path) will help them in selecting the "best" path to reach each destination. Measurements show that the AS-Path is not a good indication of the quality of a path and more recent systems (e.g. Cisco OER or routescience and others) rely on active or passive measurements to determine path quality and select the best path to reach each destination. For those recent systems, a full BGP routing table is not a requirement. I don't expect that multihomed customers will continue to expect full BGP routing tables. 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 Mon Apr 02 11:36:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOZl-0007hk-M4; Mon, 02 Apr 2007 11:36:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOZk-0007hf-A7 for ram@iab.org; Mon, 02 Apr 2007 11:36:08 -0400 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOZj-0000L4-0e for ram@iab.org; Mon, 02 Apr 2007 11:36:08 -0400 Received: from [134.129.105.135] (dyn135.wireless-105.ndsu.NoDak.edu [134.129.105.135]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l32FZpB3017951 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 2 Apr 2007 10:35:52 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4610BF94.7090508@zurich.ibm.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> <4610BF94.7090508@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4DC217A1-A6B2-4C36-88C4-5C59FEA6D43C@ndsu.edu> Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] Re: ICMP error dependency in LISP Date: Mon, 2 Apr 2007 10:35:00 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.7 (--) 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 Apr 2, 2007, at 3:32 AM, Brian E Carpenter wrote: > On 2007-03-31 10:13, Dino Farinacci wrote: > ... >> The Internet is best-effort, we are not trying to make datagram >> delivery more reliable. If a EID mapping has multiple locators and >> the ETR indicates the priority of each locator is the same, the >> ITR can load-split traffic among the locators. > > That raises the spectre of out-of-order delivery, which can be very > painful for the transport layer. I think it would be an interesting approach to load balancing or TE if the packets contained the multiple addresses of the destination plus the ratio the destination would like sent to each address. For example 25% to address A and 75% to address B. Of course for real time data like voice you could have a Don't Load Balance Bit. ( I think there was mention of something similar for STCP in the Architecture-Discuss list). --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOax-0000jH-4X; Mon, 02 Apr 2007 11:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOav-0000i9-EN for ram@iab.org; Mon, 02 Apr 2007 11:37:21 -0400 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOat-0000Uf-1P for ram@iab.org; Mon, 02 Apr 2007 11:37:21 -0400 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 l32FbIbm027998 for ; Mon, 2 Apr 2007 15:37:18 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.3) with ESMTP id l32FbImq2490502 for ; Mon, 2 Apr 2007 16:37:18 +0100 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 l32FbHwx030467 for ; Mon, 2 Apr 2007 16:37:17 +0100 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 l32FbHGv030456; Mon, 2 Apr 2007 16:37:17 +0100 Received: from [9.146.220.138] (sig-9-146-220-138.de.ibm.com [9.146.220.138]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA279496; Mon, 2 Apr 2007 17:37:16 +0200 Message-ID: <4611232A.2030006@zurich.ibm.com> Date: Mon, 02 Apr 2007 17:37:14 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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-04-02 17:29, Fleischman, Eric wrote: >> From: Brian E Carpenter [mailto:brc@zurich.ibm.com] >> LISP seems to lead to a world with 10M PI customers, and therefore a >> PI to PA map with 10M entries. > > I understand your concern, but LISP need not be deployed in this > fashion. If the tunnel boundaries are deep within the ISP, perhaps at > their borders with other ISPs, then they will aggregate the end users > they support, much like the current system. But I think we need to design the locator mapping service to deal with the worst case; if that is really 10M entries I am not too frightened. It isn't the same problem as 10M DFZ routes. > > Unlike the current system, both the ISP and the end user are provided > flexibility that don't currently exist. With LISP, ISPs are presented > huge opportunities for market differentiation and end users are > presented an opportunity to address their infrastructures as they see > fit. > > Issues that are currently the concern of the entire Internet because > everyone impacts everyone else in the current model now become business > issues negotiated between the local ISP and the end user because the ISP > (and their confederations) now become mini-Internets, modularizing the > true Internet. > > LISP needn't be an all-or-nothing solution. I envision strong market > pressures preserving L2VPN and L3VPN, in addition to supporting LISP as > the generic service for most end users. And my question was really about whether these are two models, or simply two tunings of the same model. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:37:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOb1-0000nO-Iq; Mon, 02 Apr 2007 11:37:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOb0-0000lt-Nl for ram@iab.org; Mon, 02 Apr 2007 11:37:26 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOax-0000VJ-DC for ram@iab.org; Mon, 02 Apr 2007 11:37:26 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 08:37:23 -0700 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 l32FbMlk019082 for ; Mon, 2 Apr 2007 08:37:22 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32FbMA8005168 for ; Mon, 2 Apr 2007 15:37:22 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4611220A.6030401@info.ucl.ac.be> References: <200704021436.l32EagJ93899@merlot.juniper.net> <924A2FFC-A308-439C-A761-31288224A34E@cisco.com> <4611220A.6030401@info.ucl.ac.be> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <37F71545-6006-4DFD-A45B-C00A6EA3401F@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 08:37:43 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1360; t=1175528242; x=1176392242; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=4oHv81Q/cZzRj8lpSC7CTaVjjUdmZEbwEMwZfW9MmiI=; b=whE5r2JIXnWYQVBA7p108+7JMpbj3s6J6t3yPV8s0C/daAe6HElBC51d5FwvQaDY0ucBkueY dUZuinhupU8tF9vbaujoKjISNDgumZGdpKIdJsCC5oS9CsGLSQVmlv77; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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 Apr 2, 2007, at 8:32 AM, Olivier Bonaventure wrote: > Measurements > show that the AS-Path is not a good indication of the quality of a > path > and more recent systems (e.g. Cisco OER or routescience and others) > rely > on active or passive measurements to determine path quality and select > the best path to reach each destination. For those recent systems, a > full BGP routing table is not a requirement. > > I don't expect that multihomed customers will continue to expect full > BGP routing tables. I understand what you're saying, but disagree with the prevalence of various optimization schemes for outbound traffic. Some endpoint networks are certainly interested in those things, and awareness of them (quite separate from a discussion of their efficacy and/or desirability) is growing, but I believe this is far from the default (pardon the pun, heh) expectation, and will remain so for quite some time. [All of this is really off-topic, anyways, as Ross pointed out that he was talking about ingress into multihomed endpoint networks, not egress from them.] ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:45:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOiS-0006ZY-Pe; Mon, 02 Apr 2007 11:45:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOiS-0006Pj-1i for ram@iab.org; Mon, 02 Apr 2007 11:45:08 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOhr-0001ff-5m for ram@iab.org; Mon, 02 Apr 2007 11:44:32 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 17:44:30 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32FiU3B027957; Mon, 2 Apr 2007 17:44:30 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp406.cisco.com [10.61.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32FiTlZ018308; Mon, 2 Apr 2007 15:44:30 GMT Message-ID: <461124DB.7010106@cisco.com> Date: Mon, 02 Apr 2007 17:44:27 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> In-Reply-To: <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2254; t=1175528670; x=1176392670; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=44mlLtAXDda+8HcOEULuglpqpCKMNCJY7K9XtbHsmfU=; b=kIpdkZBdMBqBa7k7fP8/mUDx3LHmvcB9etkaqoBprrfvCxU2apmYB97WwA6eSeZrb4TFUECp 5t7nKNqujN636LeP8+TvFdZSr/e5hs27le5+Llqk3o5SAUaKvKq1sUr1; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 Dave, > Eliot, > > On Apr 1, 2007, at 9:54 AM, Eliot Lear wrote: >>>> Lookups are a non-starter because of the lookup latency and what >>>> you do with a packet on a cache miss >>> I wonder if the folks who argued against moving from HOSTS.TXT to >>> the DNS used the same rationale... :-) >> Remember, with LISP we're talking about ROUTERS switching PACKETs and >> not END HOSTS establishing a communication (be it UDP, TCP, SCTP, or >> whatever). > > The routers won't need to switch packets until an end host tries to > establish communication. Right. All I'm saying is that a router can't do an off box lookup. It's just a non-starter (see below). > >> My concern is latency in establishing a connection when everything is >> in a nominal state, particularly due to an off-the-box lookup. > > The normal state will be a lookup in local cache. Yes, the initial > state will require an off-the-box lookup which has increased latency. > The cost of this additional latency at communication initiation is > what you pay for increased scalability, flexibility, and > updatability. You only fetch what you need when you need it. > Contrast this to the RADB model which requires all the mapping data to > be propagated globally regardless of any usage patterns. How big is > this table going to be (that is, how many end points will their be in > the routing system)? Yes, you can propagate diffs, but you still have > to propagate the initial table to do the diffs against. How long will > that initial table download take? At least initially the table + RIB is likely to not be much larger than the RIB itself. Over time I would expect table+RIB to actually shrink for LISP versus what it would have been with the additional multihoming. This is why I asked all those questions earlier about whether size matters. If it's simply rate of transactions and not size, life is pretty good for LISP. > >> Yes, you can do it with DNS, but that will produce unacceptable latency. > > You make this assertion like it is axiomatic. What is your definition > of acceptable? An order of magnitude or three under 1 ms. And buffering the packet is also a non-starter. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:46:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOjn-0007l8-3c; Mon, 02 Apr 2007 11:46:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOiZ-0006br-Jv for ram@iab.org; Mon, 02 Apr 2007 11:45:15 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOdX-0000yD-Jo for ram@iab.org; Mon, 02 Apr 2007 11:40:07 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 08:40:03 -0700 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 l32Fe3IM032256 for ; Mon, 2 Apr 2007 08:40:03 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32Fe2A8006745 for ; Mon, 2 Apr 2007 15:40:02 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <4611232A.2030006@zurich.ibm.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 08:40:24 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=602; t=1175528403; x=1176392403; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP] |Sender:=20; bh=L3jemKHNOG/whr67H0h84RTbDy7u2m8w6DDy9adQGEg=; b=vqTHrkz2VgnwSpVtCGFupKYD69cJpCASch6Q3rF7EQHNKtacVcd9GU+23cODoA74co01JaMO gx7u83FsKdnxmkh6sZ++WHzgTKt+Vq32+LcanwRi4uTHLR9TlLBosGID; 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 2, 2007, at 8:37 AM, Brian E Carpenter wrote: > But I think we need to design the locator mapping service to deal > with the worst case; if that is really 10M entries I am not too > frightened. It isn't the same problem as 10M DFZ routes. Here's one extrapolation of the possible future in this regard: ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 11:57:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOtc-0003Vt-KA; Mon, 02 Apr 2007 11:56:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYOtZ-0003VW-PZ for ram@iab.org; Mon, 02 Apr 2007 11:56:37 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYOtY-0004eC-CC for ram@iab.org; Mon, 02 Apr 2007 11:56:37 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32Fga61034298; Mon, 2 Apr 2007 08:42:36 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 08:56:13 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 08:56:13 -0700 In-Reply-To: <461124DB.7010106@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 08:56:11 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Eliot, On Apr 2, 2007, at 8:44 AM, Eliot Lear wrote: >>> Yes, you can do it with DNS, but that will produce unacceptable >>> latency. >> You make this assertion like it is axiomatic. What is your >> definition of acceptable? > An order of magnitude or three under 1 ms. Why? > And buffering the packet is also a non-starter. Why? Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 12:21: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 1HYPFn-0005BW-CI; Mon, 02 Apr 2007 12:19:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPFm-0005BR-C9 for ram@iab.org; Mon, 02 Apr 2007 12:19:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPFl-0000eQ-3A for ram@iab.org; Mon, 02 Apr 2007 12:19:34 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 18:19:33 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32GJWQU006759; Mon, 2 Apr 2007 18:19:32 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp406.cisco.com [10.61.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32GJUlZ000545; Mon, 2 Apr 2007 16:19:30 GMT Message-ID: <46112D10.8010201@cisco.com> Date: Mon, 02 Apr 2007 18:19:28 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> In-Reply-To: <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1174; t=1175530772; x=1176394772; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=1LXPCC8HHbdOGpHwyL6qQBhCk+32ABGZHRazmCP3JZw=; b=lxeGatiKUlySvBPCBXDm/Sic/h0RFiuJCPrUhYohDx7BVBS5WNwNt0F5oKVvGMlRDHBba10M hbzppr2VUMi/FQl1WrFq/GhyzV+lVohAC6ZanhOrmTtpGWESmlw/OCZH; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 David Conrad wrote: > Eliot, > > On Apr 2, 2007, at 8:44 AM, Eliot Lear wrote: >>>> Yes, you can do it with DNS, but that will produce unacceptable >>>> latency. >>> You make this assertion like it is axiomatic. What is your >>> definition of acceptable? >> An order of magnitude or three under 1 ms. > > Why? Because we shouldn't engineer delay into the system, and second, because that is what matches existing behavior today. Want to take a guess as to which applications need that 1ms and which don't? I sure as heck don't want to be there. > >> And buffering the packet is also a non-starter. > > Why? First because that's not what routers should be for. Routers are for *delivering* packets not *storing* them. Moreover, it's not just one packet- it's going to be a train of packets, more likely. People keep talking as if we're talking about a single packet, presuming that in each case a conversation is beginning. That may be a false assumption. Beyond that, the caching semantics and "active conversations" are quite a lot of hair that I believe you should demonstrate need prior to imposing. Regards, Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 12:33:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPRY-0001p5-FE; Mon, 02 Apr 2007 12:31:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPRW-0001kT-Jp for ram@iab.org; Mon, 02 Apr 2007 12:31:42 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPRT-0002Wy-9I for ram@iab.org; Mon, 02 Apr 2007 12:31:42 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32GVaG8029228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 09:31:36 -0700 (PDT) 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 l32GVXQr016875; Mon, 2 Apr 2007 09:31:33 -0700 (PDT) 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 l32GV8Ku015861; Mon, 2 Apr 2007 09:31:16 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:31:14 -0700 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: [RAM] MANETs and LISP Date: Mon, 2 Apr 2007 09:31:13 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] MANETs and LISP Thread-Index: AcdzMIZzvp7OzxBPRtShkuRuSBpg0QCC84lw References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 02 Apr 2007 16:31:14.0760 (UTC) FILETIME=[54FF6C80:01C77544] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 >From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 >Does a LISP-like solution lend itself to MANET? =20 Since I've been working with MANET for many years now, this is a point that I have thought about quite a bit. In my personal opinion (i.e., I don't expect you to agree), the historic IP protocol is inherently designed for stable environments and becomes severely challenged by MANET attributes (e.g., mobility, signal intermittence, transitory relationships). The two (i.e., traditional IP and MANET) can (and do) coexist, but their interface point(s) needs to satisfy the requirements of both communities.=20 It is my personal opinion (i.e., I again don't expect you to agree) that because BGP is particularly poorly suited for supporting MANETs (e.g., pairwise relationships, no discovery), that a natural place to relate MANETs with traditional IP is at the AS boundary, because to extend MANETs beyond the AS boundary needs to overcome the vast problems that BGP has in highly mobile, highly signal intermittence environments.=20 However, regardless of where the boundary is placed, the MANET entity needs to be represented to the larger stable network environment from a node that appears to be stable to the stable environment, and it is desirable that the MANET reachability information reported from that node to the stable environment is dampened (e.g., abstracted) to reduce the detrimental affects of the MANET environment upon the stable environment (e.g., route churning). ISPs are currently a key part of the "stable environment" and to interface with them, the MANET BGP interface node and the MANET community it represents needs to be reported to appear to be as stable as possible. This is true for all Internet models using BGP interfaces, including LISP. >Is MANET at some point=20 >in the foreseeable future going to become the norm, with complete=20 >disintermediation between what we now think of as SPs and customers? MANET is already the norm in some communities, but practitioners of IP are highly incentivized to restrict MANET deployments to boundaries that are as clearly defined as possible, because of the challenges that OSPF, IS-IS, BGP, PIM-DM, PIM-SM, etc. have in supporting MANET, particularly as a MANET community itself scales to hundreds or thousands of nodes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 12:41:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPaR-0007uq-ED; Mon, 02 Apr 2007 12:40:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPaQ-0007qb-EI for ram@iab.org; Mon, 02 Apr 2007 12:40:54 -0400 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 1HYPaO-0004Ld-4M for ram@iab.org; Mon, 02 Apr 2007 12:40:54 -0400 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 l32Gepvo026467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 09:40:51 -0700 (PDT) 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 l32Geo2k002798; Mon, 2 Apr 2007 09:40:50 -0700 (PDT) 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 l32GedOo002316; Mon, 2 Apr 2007 09:40:50 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 09:40:44 -0700 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: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 09:40:44 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: AcdzMIZzvp7OzxBPRtShkuRuSBpg0QCEFPhQ References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 02 Apr 2007 16:40:44.0923 (UTC) FILETIME=[A8D764B0:01C77545] 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 >From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 >Does a LISP-like solution retain the concept of a single global=20 >Internet? If not, have we 'outgrown' that concept due to various=20 >technical, business, and political reasons? My concern is that I have been unable to articulate what our current Internet Architecture is. I spent the entire Vancouver IETF privately asking our leadership for their vision, and I became very discouraged from my queries.=20 In many ways, LISP is nothing other than a formalization of the current IPv6-IPv4 migration techniques. The difference, of course, is that the current migration techniques postulate an eventual IPv6 end state.=20 If you believe that a pure IPv6 future will occur, then LISP could be a possible transition state for you, but not an appropriate final state.=20 However, if you believe as I do that current IPv6 design is inherently self-defeating, then LISP represents a possibly achievable replacement for our current mythology and a possible realistic basis to become our current Internet Architecture. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 12:58:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPpk-0003a5-Qo; Mon, 02 Apr 2007 12:56:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPpj-0003Zy-IA for ram@iab.org; Mon, 02 Apr 2007 12:56:43 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPpi-0007AB-B4 for ram@iab.org; Mon, 02 Apr 2007 12:56:43 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2007 12:56:43 -0400 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 l32Gugt8011001; Mon, 2 Apr 2007 12:56:42 -0400 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 l32GuflG009431; Mon, 2 Apr 2007 16:56:41 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:56:41 -0400 Received: from [192.168.0.4] ([10.82.209.169]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:56:40 -0400 In-Reply-To: <4611232A.2030006@zurich.ibm.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@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: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 09:56:44 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 16:56:40.0932 (UTC) FILETIME=[E2AACA40:01C77547] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=498; t=1175533002; x=1176397002; c=relaxed/simple; s=rtpdkim1001; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP] |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=9hkbqq1XTLwJpG1NfuPJyNqDX+JNDx12Z740viKxhpI=; b=bXsMSmKoj5m0fWGzD5t96rPnb10DS5lUYeu/UsDYJ2dyFSRT9WvOp3Kuz5xadejiQ/TMJwFc OQQDe1VZN2Orwzx4doEJ8gWPftaqp+WuRuwIk+sfE6HZzbg0rxmKepmG; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: "Fleischman, Eric" , 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 I think we need to design the locator mapping service to deal > with the worst case; if that is really 10M entries I am not too > frightened. It isn't the same problem as 10M DFZ routes. I am actually not worried about the aggregateability of the EID- prefix space. Since it will be based on an allocation hierarchy and not a topology heirarchy. What I do worry about is the locator-set placement which can cause deaggregateability of the allocated EID-prefix block. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:02:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPvG-0007XI-LB; Mon, 02 Apr 2007 13:02:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPvF-0007XB-Ia for ram@iab.org; Mon, 02 Apr 2007 13:02:25 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYPvE-0008F4-45 for ram@iab.org; Mon, 02 Apr 2007 13:02:25 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l32H290P035399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 19:02:09 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.12.10) with ESMTP id l32H29VG017926; Mon, 2 Apr 2007 19:02:09 +0200 Date: Mon, 2 Apr 2007 19:02:09 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Fleischman, Eric" Subject: Re: [RAM] LISP and the Global Internet Architecture In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-226418608-456767159-1175533329=:1566" X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 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 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---226418608-456767159-1175533329=:1566 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mux2.uit.no id l32H290P035399 sorry if this post is a bit off topic but one question popped into my hea= d=20 when I=B4ve been reading through the latest posts made on this list.. On Mon, 2 Apr 2007, Fleischman, Eric wrote: > However, if you believe as I do that current IPv6 design is inherently > self-defeating, then LISP represents a possibly achievable replacement > for our current mythology and a possible realistic basis to become our > current Internet Architecture. What has to be changed with IPv6 to avoid it being self-defeating? --=20 ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- ---226418608-456767159-1175533329=:1566 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 ---226418608-456767159-1175533329=:1566-- From ram-bounces@iab.org Mon Apr 02 13:03:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPwN-0007xF-03; Mon, 02 Apr 2007 13:03:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYPwL-0007x9-Dw for ram@iab.org; Mon, 02 Apr 2007 13:03:33 -0400 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 1HYPwK-0008Uf-65 for ram@iab.org; Mon, 02 Apr 2007 13:03:33 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32H3VJK015509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 12:03:31 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l32H3VYg012145; Mon, 2 Apr 2007 12:03:31 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l32H3T99012088; Mon, 2 Apr 2007 12:03:31 -0500 (CDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:03:30 -0700 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: [RAM] Are LISP and L2VPN/L3VPN different models? Date: Mon, 2 Apr 2007 10:03:29 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EB0@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <4611232A.2030006@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Are LISP and L2VPN/L3VPN different models? Thread-Index: Acd1PNDYLA4XofJKT5Sl4FybcEatgQACfvgg References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> From: "Fleischman, Eric" To: X-OriginalArrivalTime: 02 Apr 2007 17:03:30.0800 (UTC) FILETIME=[D6F7AF00:01C77548] 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 >From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 >> LISP needn't be an all-or-nothing solution. I envision strong market=20 >> pressures preserving L2VPN and L3VPN, in addition to supporting LISP=20 >> as the generic service for most end users. >And my question was really about whether these are two models, or=20 >simply two tunings of the same model. This is an excellent question, Brian. In my mind, they are two very different models, and I wonder if different answers to this question doesn't underlie some of this discussion?=20 I believe that they are two models because we currently use L3VPN (or L2VPN) to connect geographically distributed parts of our own company together. For example, we arrange with our ISPs to support MLPS paths across their infrastructures so that a part of our company in Region A can talk to a part of our company in Region B. I imagine that L3VPN can also be used to link together privately defined confederations of end users from different ASes into a private network.=20 Regardless, the L2VPN and L3VPN service is what I refer to as "range extension" because it appears to us to be a logical link from our point of view. This logical link can be located at any level of the IP Topology hierarchy. However, I believe that LISP is fundamentally different. LISP is what I call "reach back" because it provides a mechanism for ASes to communicate together via BGP. That is, LISP represents an implementation of the network of networks and provides a logical mesh supporting formal BGP connectivity between ASes. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:15:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ72-00083L-Mp; Mon, 02 Apr 2007 13:14:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ72-00081c-3k for ram@iab.org; Mon, 02 Apr 2007 13:14:36 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQ70-000203-Ho for ram@iab.org; Mon, 02 Apr 2007 13:14:36 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32H0W61034453; Mon, 2 Apr 2007 10:00:32 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 10:14:09 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 10:14:09 -0700 In-Reply-To: <46112D10.8010201@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:14:06 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Eliot, On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: >> [latency] > Because we shouldn't engineer delay into the system, There are already numerous delays engineered into the system. > and second, because that is what matches existing behavior today. How long does it take for a router that takes full routes when it initially started to be able to forward packets? A system based on a pull model would be able to avoid this delay. > Want to take a guess as to which applications need that 1ms and > which don't? Why 1ms? Why not 10ms or 0.1ms? None of these numbers appear to be backed up by any empirical evidence. > I sure as heck don't want to be there. Name one application that can't tolerate a delay on initial start up. Realistically, since we're talking about a datagram based network with best effort delivery, the additional latency that would exist in an on-demand pull-based model would be lost in the noise of initial communication establishment. >> [buffering] > First because that's not what routers should be for. Routers are > for *delivering* packets not *storing* them. Good thing we don't need ARP. Routers already buffer. > Moreover, it's not just one packet- it's going to be a train of > packets, more likely. Last I checked, TCP-based traffic outweighed all other traffic significantly. > People keep talking as if we're talking about a single packet, > presuming that in each case a conversation is beginning. That may > be a false assumption. Yes, there can be cases where the first packet in a transaction is actually a set of packets, in which case, the router has the choice of buffering or dropping until the mapping can be performed. In an ideal world, I would agree that it would be really nice to have the entire mapping table local. However, I believe this simply won't scale. You're moving the routing table thrash problem from a smallish set of really well connected core routers down to every edge system (for some value of the variable "edge"). You can "solve" this problem somewhat by artificially constraining how frequently the table changes, but you're the one who is saying we shouldn't engineer delays into the system. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:16:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ8V-0000OL-MA; Mon, 02 Apr 2007 13:16:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ8S-0000OC-M6 for ram@iab.org; Mon, 02 Apr 2007 13:16:04 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQ8R-0002H5-9K for ram@iab.org; Mon, 02 Apr 2007 13:16:04 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 13:16:02 -0400 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 l32HFuIA022598; Mon, 2 Apr 2007 13:15:56 -0400 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 l32HFBlc015813; Mon, 2 Apr 2007 17:15:53 GMT 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); Mon, 2 Apr 2007 13:15:42 -0400 Received: from [192.168.0.4] ([10.82.209.169]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:15:41 -0400 In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EAB@XCH-NW-6V1.nw.nos.boeing.com> References: Your message of "Mon, 02 Apr 2007 09:31:39 EDT."<20070402133139.C8BB5872C1@mercury.lcs.mit.edu> <200704021342.l32Dg7J83715@merlot.juniper.net> <474EEBD229DF754FB83D256004D0210802584EAB@XCH-NW-6V1.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: <08E2AF13-D4ED-4F6C-80F6-E1699CA55861@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 10:15:45 -0700 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:15:41.0881 (UTC) FILETIME=[8AB9CA90:01C7754A] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1371; t=1175534156; x=1176398156; c=relaxed/simple; s=rtpdkim1001; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP]=20 |Sender:=20 |To:=20=22Fleischman,=20Eric=22=20; bh=nvkPjYYhq7PHjNhlMp1mf8q4YMTQVqK3S+9LcN89cKA=; b=sSuAoXFK3dvsqRmNB/h7GhkvBRmp0gzHNKg8MOgjW+2vAG0tAVW9nyeU/RlnOuRVrLsC/RRs WhByA+oqqmjEog8WEKu6d77jzURgHiLK8R7+r0nKpjxF93Z283PyibOE; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: jnc@mercury.lcs.mit.edu, 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 > If the ISPs place the tunnel end points at their customers' premises, > like the PE-CE boundary of L3VPN, then there are indeed N**2 > tunnels and > the approach will not scale, IMO. There are not N^2 tunnels. In fact, the term "tunnel" might be too strong a term because it can convey some static nature of using this mechanism. In LISP, you can view the tunneling part simply as a "encapsulation" which requires no control-plane state. The state and size used for the "EID-cache" is only for the aggregate flows that are flowing through the ITR. It is very much on-demand. I really believe the model will have to be 3-way hybrid, that is: o You push the aggregateable allocation prefixes to high-level entities. o Those *can* be pushed to ITRs, which store such mappings *only* in control-plane memory. Or the ITRs can do a lower-latency request/ reply transaction to the higher-level entities. o The forwarding cache contains EID-prefix to RLOC encapsulation mappings for on demand destinations. And for Ross's concern, when you match the "default route" in the ITR, that means the destination is global (or outside of your site), so you then do either another table lookup in the EID-cache, or you put the EID-prefixes in the same FIB so longest match finds them before the default route. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:16:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ8n-0000fj-QO; Mon, 02 Apr 2007 13:16:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQ8m-0000ej-8t for ram@iab.org; Mon, 02 Apr 2007 13:16:24 -0400 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 1HYQ8k-0002Iu-Vr for ram@iab.org; Mon, 02 Apr 2007 13:16:24 -0400 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 l32HGLCN025325 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 12:16:22 -0500 (CDT) 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 l32HGLYt002059; Mon, 2 Apr 2007 10:16:21 -0700 (PDT) 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 l32HGIgb001979; Mon, 2 Apr 2007 10:16:20 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:16:20 -0700 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] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:16:19 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1SKp+bdp7WwNrSM2G2rgp0bQNWwAAEakg References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: X-OriginalArrivalTime: 02 Apr 2007 17:16:20.0263 (UTC) FILETIME=[A19A6B70:01C7754A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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: Roger Jorgensen [mailto:rogerj@jorgensen.no]=20 >What has to be changed with IPv6 to avoid it being self-defeating? The architecture must not require widespread end user deployment in order to work, as it currently does -- either that, or there must be a truly compelling reason from the end user perspective for the end user to want to support IPv6.=20 IPv6 was originally designed to solve ISP problems to which the end user has no visibility. IPv6 represents an expense for the end user but does not offer any functionality to justify that expense -- there is no killer app for IPv6. Until a killer app emerges, the end user is naturally motivated to avoid introducing non-value-added variability to their infrastructure and thereby significantly increase their own operations and support costs. Worse yet, until IPv6 permitted PI addresses, it represented a mechanism that required large end users to be held captive to their ISPs. This is untenable to any end user and violates a fundamental law of economics that businesses support the needs of their customers. Rather, the model originally used by IPv6 was that customers support the needs of their vendors. Not!!! _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:19:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQBq-0005HU-Gm; Mon, 02 Apr 2007 13:19:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQBp-0005Dc-Au for ram@iab.org; Mon, 02 Apr 2007 13:19:33 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQBl-0002qK-UX for ram@iab.org; Mon, 02 Apr 2007 13:19:33 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32HJSa6005059 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 10:19:29 -0700 (PDT) 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 l32HJRgb003047; Mon, 2 Apr 2007 10:19:27 -0700 (PDT) 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 l32HJDI8002513; Mon, 2 Apr 2007 10:19:19 -0700 (PDT) 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); Mon, 2 Apr 2007 10:19:19 -0700 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] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:19:18 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774871@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acd1Sm71qN5oPruSRnSf64mB+ZgjOwAAA3nQ References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> From: "Templin, Fred L" To: "David Conrad" , "Eliot Lear" X-OriginalArrivalTime: 02 Apr 2007 17:19:19.0172 (UTC) FILETIME=[0C3DC440:01C7754B] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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 David/Eliot, This goes back to what I said in an earlier message: + You seem to be assuming that the mapping will be driven by + the first packet out the door; I'm not assuming that at all. + For inter-site communications, there will always be an initial + FQDN-to-locator resolution before a session starts, and the + mapping can be done then before any packets are sent. So, I really don't see a reason to be worried about new delay models at all. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: David Conrad [mailto:drc@virtualized.org]=20 > Sent: Monday, April 02, 2007 10:14 AM > To: Eliot Lear > Cc: ram@iab.org > Subject: Re: [RAM] Incremental Deployment of LISP >=20 > Eliot, >=20 > On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: > >> [latency] > > Because we shouldn't engineer delay into the system, >=20 > There are already numerous delays engineered into the system. >=20 > > and second, because that is what matches existing behavior today. >=20 > How long does it take for a router that takes full routes when it =20 > initially started to be able to forward packets? A system=20 > based on a =20 > pull model would be able to avoid this delay. >=20 > > Want to take a guess as to which applications need that 1ms and =20 > > which don't? >=20 > Why 1ms? Why not 10ms or 0.1ms? None of these numbers appear to be =20 > backed up by any empirical evidence. >=20 > > I sure as heck don't want to be there. >=20 > Name one application that can't tolerate a delay on initial start =20 > up. Realistically, since we're talking about a datagram based =20 > network with best effort delivery, the additional latency that would =20 > exist in an on-demand pull-based model would be lost in the noise of =20 > initial communication establishment. >=20 > >> [buffering] > > First because that's not what routers should be for. Routers are =20 > > for *delivering* packets not *storing* them. >=20 > Good thing we don't need ARP. >=20 > Routers already buffer. >=20 > > Moreover, it's not just one packet- it's going to be a train of =20 > > packets, more likely. >=20 > Last I checked, TCP-based traffic outweighed all other traffic =20 > significantly. >=20 > > People keep talking as if we're talking about a single packet, =20 > > presuming that in each case a conversation is beginning. That may =20 > > be a false assumption. >=20 > Yes, there can be cases where the first packet in a transaction is =20 > actually a set of packets, in which case, the router has the choice =20 > of buffering or dropping until the mapping can be performed. >=20 > In an ideal world, I would agree that it would be really nice=20 > to have =20 > the entire mapping table local. However, I believe this=20 > simply won't =20 > scale. You're moving the routing table thrash problem from a =20 > smallish set of really well connected core routers down to=20 > every edge =20 > system (for some value of the variable "edge"). You can=20 > "solve" this =20 > problem somewhat by artificially constraining how frequently the =20 > table changes, but you're the one who is saying we shouldn't=20 > engineer =20 > delays into the system. >=20 > Rgds, > -drc >=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 Apr 02 13:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQF5-0007Sq-OK; Mon, 02 Apr 2007 13:22:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQF4-0007SZ-AY for ram@iab.org; Mon, 02 Apr 2007 13:22:54 -0400 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 1HYQF3-0003RB-1J for ram@iab.org; Mon, 02 Apr 2007 13:22:54 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 02 Apr 2007 10:22:53 -0700 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32HMqDb025003; Mon, 2 Apr 2007 10:22:52 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32HMHxD012465; Mon, 2 Apr 2007 17:22:52 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:22:35 -0400 Received: from [192.168.0.4] ([10.82.209.169]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:22:34 -0400 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:22:37 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:22:35.0052 (UTC) FILETIME=[80FEAEC0:01C7754B] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1091; t=1175534572; x=1176398572; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=Bp9CG2aozxOMBK/5Ek9enA6bBs5VQrDZnFMcjyCctu4=; b=qE0VAIJNFySLk6LSk60C99ita0G/9rJk7cg9AowyXwcWyGgQUBWTrzXg1ngtP08Ku5ZC5rby pvS5cG+TmaPF7BOlgTJHWHFgpzN0GfevuGFP2WjLg1XH8S8S+lMKit1l; 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: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: >>> [latency] >> Because we shouldn't engineer delay into the system, > > There are already numerous delays engineered into the system. David, let me try this to see how Eliot will react. Eliot, (like Fred Templin's idea), what if the host pointed it's DNS server address to a router, say the ITR router. So when the host does a DNS lookup, the router intercepts it (not really intercepts it because the UDP packet is addressed to the router), sends it on but also adds a request record for say a RLOC RR. The ITR will have to make the request come from the ITR's source address so the reply returned can get the RLOC RR stored in the EID- to-RLOC mapping cache by the ITR. Then the ITR can return the A record reply to the host. All this happens before the first TCP SYN is sent by the host. There is increased latency, but the host doesn't really know any differently. So question to beg is will IT managers feel comfortable pointing DNS server addresses to this map-n-encap routers. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:23:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQFY-0007zV-D3; Mon, 02 Apr 2007 13:23:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQFX-0007y1-3Q for ram@iab.org; Mon, 02 Apr 2007 13:23:23 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQFV-0003ZS-LS for ram@iab.org; Mon, 02 Apr 2007 13:23:23 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32H9f61034489; Mon, 2 Apr 2007 10:09:41 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 10:23:17 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 10:23:17 -0700 In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:23:15 -0700 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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, On Apr 2, 2007, at 9:40 AM, Fleischman, Eric wrote: >> From: Roland Dobbins [mailto:rdobbins@cisco.com] >> Does a LISP-like solution retain the concept of a single global >> Internet? We gave "a single global Internet" up when IPv6 was standardized since it created a parallel ("dual stack") Internet that uses the same domain name tree. > However, if you believe as I do that current IPv6 design is inherently > self-defeating, then LISP represents a possibly achievable replacement > for our current mythology and a possible realistic basis to become our > current Internet Architecture. IPv6, as defined, is little more than IPv4 with more bits. As lots of people pointed out lots of times, the size of the address wasn't really the problem, rather the scalability of the routing system was. We're now trying to come up with a solution to the scalability problem that doesn't involve "use more thrust". LISP and its ilk are the first realistic attempts to actually deal with scaling the Internet up. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:35:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQPl-0005Jq-VN; Mon, 02 Apr 2007 13:33:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQPj-0005Bo-Uh for ram@iab.org; Mon, 02 Apr 2007 13:33:55 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQPi-0005uu-MH for ram@iab.org; Mon, 02 Apr 2007 13:33:55 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 02 Apr 2007 13:33:54 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32HXscl025289; Mon, 2 Apr 2007 13:33:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l32HXKle021430; Mon, 2 Apr 2007 17:33:49 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:33:35 -0400 Received: from [192.168.0.4] ([10.82.209.169]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:33:35 -0400 In-Reply-To: <4610BF94.7090508@zurich.ibm.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> <4610BF94.7090508@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: <5C4EDAB9-F601-4936-8B13-E412923BF7E1@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Re: ICMP error dependency in LISP Date: Mon, 2 Apr 2007 10:33:38 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:33:35.0449 (UTC) FILETIME=[0A9F4490:01C7754D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1614; t=1175535234; x=1176399234; c=relaxed/simple; s=rtpdkim2001; 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=20ICMP=20error=20dependency=20in=20LISP |Sender:=20 |To:=20Brian=20E=20Carpenter=20; bh=f3Ag3wAhz8z7yRnJW98JzlUFFkNHIa0ZMpwccspv6DQ=; b=SILscZTaqvnSoHnG1DqKAgupv/YvT9Etx5jyCYk84/wewLL04NilZlTwaJz1aahVm0rTng7i fV2iHsEgqxgtV5Mr/UWjqsUmRBbXX0UqQD8xEPe8fSLr/L31HD22NdKJ; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: Margaret Wasserman , 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 >> The Internet is best-effort, we are not trying to make datagram >> delivery more reliable. If a EID mapping has multiple locators and >> the ETR indicates the priority of each locator is the same, the >> ITR can load-split traffic among the locators. > > That raises the spectre of out-of-order delivery, which can be very > painful for the transport layer. A traditional tradeoff between route-based versus flow-based forwarding. And the decent middle ground adopted today is hashing. So for an EID-prefix match, you hash on the 4-tuple say, and then pick a Locator (and stick with it) from the Locator-set. Brian, don't worry, be happy. ;-) >>> d) some poor firewall or ACL filters out the ICMP message at the >>> ICMP >>> originator's domain, in transit, or at the recipient's domain? >> The protocol needs feedback. If you choose UDP to return the >> mapping or error message, those could get filtered as well. There >> is no magic here, you have to fix the filters. > > Well, I have to ask the same question I recently asked about shim6 > error messages: will lost ICMP packets break the protocol? If yes, > then I think that signalling in-band (i.e. in packets that are part > of the target session) is much preferable. "Fix the filters" isn't > a deployable feature of LISP, IMHO, because different people > control the > filters. Then you forward into black-holes. That tends to get people's attention to get the problem fixed. There is no silver bullet here Brian. You know that, you've been doing this too long as well. ;-) Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:37:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQSr-0006mq-22; Mon, 02 Apr 2007 13:37:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQSp-0006lb-OO for ram@iab.org; Mon, 02 Apr 2007 13:37:07 -0400 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 1HYQSo-0006bL-Cu for ram@iab.org; Mon, 02 Apr 2007 13:37:07 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32Hb42j011044 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 12:37:05 -0500 (CDT) 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 l32Hb48S016521; Mon, 2 Apr 2007 10:37:04 -0700 (PDT) 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 l32Hb2ck016356; Mon, 2 Apr 2007 10:37:03 -0700 (PDT) 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); Mon, 2 Apr 2007 10:37:02 -0700 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] MANETs and LISP Date: Mon, 2 Apr 2007 10:37:01 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774872@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] MANETs and LISP Thread-Index: AcdzMIZzvp7OzxBPRtShkuRuSBpg0QCC84lwAAO8YbA= References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> From: "Templin, Fred L" To: "Fleischman, Eric" , , X-OriginalArrivalTime: 02 Apr 2007 17:37:02.0842 (UTC) FILETIME=[863CEDA0:01C7754D] X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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 agree with Eric, but I would add that it doesn't have to be particularly mobile or even ad-hoc to be considered a MANET. Here is the way I am defining MANET in my I-Ds: "(A MANET is) a connected network region that comprises MANET routers that maintain a routing structure among themselves over links with asymmetric reachability characteristics (see: [RFC2461], Section 2.2). A MANET may be as large as an Autonomous System (AS) or as small as an individual site, and may also be a subnetwork of a larger site. A MANET router (and its downstream-attached links) is a "site" unto itself, and a MANET is therefore a "site-of-sites"." So, the types of MANETs that Eric is describing are covered under this definition, but so are home networks, vehicular platforms, "sites" within large enterprises, large enterprises themselves, etc. etc. It just happens that these more static and/or managed examples are really just special cases of MANETs. Fred fred.l.templin@boeing.com > -----Original Message----- > From: Fleischman, Eric=20 > Sent: Monday, April 02, 2007 9:31 AM > To: rdobbins@cisco.com; ram@iab.org > Subject: [RAM] MANETs and LISP >=20 > >From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 > >Does a LISP-like solution lend itself to MANET? =20 >=20 > Since I've been working with MANET for many years now, this is a point > that I have thought about quite a bit. In my personal opinion (i.e., I > don't expect you to agree), the historic IP protocol is inherently > designed for stable environments and becomes severely challenged by > MANET attributes (e.g., mobility, signal intermittence, transitory > relationships). The two (i.e., traditional IP and MANET) can (and do) > coexist, but their interface point(s) needs to satisfy the=20 > requirements > of both communities.=20 >=20 > It is my personal opinion (i.e., I again don't expect you to=20 > agree) that > because BGP is particularly poorly suited for supporting MANETs (e.g., > pairwise relationships, no discovery), that a natural place to relate > MANETs with traditional IP is at the AS boundary, because to extend > MANETs beyond the AS boundary needs to overcome the vast problems that > BGP has in highly mobile, highly signal intermittence environments.=20 >=20 > However, regardless of where the boundary is placed, the MANET entity > needs to be represented to the larger stable network=20 > environment from a > node that appears to be stable to the stable environment, and it is > desirable that the MANET reachability information reported from that > node to the stable environment is dampened (e.g., abstracted)=20 > to reduce > the detrimental affects of the MANET environment upon the stable > environment (e.g., route churning). ISPs are currently a key=20 > part of the > "stable environment" and to interface with them, the MANET=20 > BGP interface > node and the MANET community it represents needs to be reported to > appear to be as stable as possible. This is true for all=20 > Internet models > using BGP interfaces, including LISP. >=20 > >Is MANET at some point=20 > >in the foreseeable future going to become the norm, with complete=20 > >disintermediation between what we now think of as SPs and customers? >=20 > MANET is already the norm in some communities, but practitioners of IP > are highly incentivized to restrict MANET deployments to=20 > boundaries that > are as clearly defined as possible, because of the challenges=20 > that OSPF, > IS-IS, BGP, PIM-DM, PIM-SM, etc. have in supporting MANET,=20 > particularly > as a MANET community itself scales to hundreds or thousands of nodes. >=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 Apr 02 13:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQTs-0006xs-3R; Mon, 02 Apr 2007 13:38:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQTq-0006xl-Ok for ram@iab.org; Mon, 02 Apr 2007 13:38:10 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQTp-0006tp-FM for ram@iab.org; Mon, 02 Apr 2007 13:38:10 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 10:38:06 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l32Hc6lk028300; Mon, 2 Apr 2007 10:38:06 -0700 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 l32Hc6AE015759; Mon, 2 Apr 2007 17:38:06 GMT 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); Mon, 2 Apr 2007 10:38:06 -0700 Received: from [192.168.0.100] ([10.21.80.188]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:38:05 -0700 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.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: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:38:11 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:38:05.0906 (UTC) FILETIME=[ABD3BB20:01C7754D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=583; t=1175535486; x=1176399486; 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:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=20vOAePMTIDz4ll9287l4if6oemkZOGwS5nQri5vh9A=; b=dBMtCSwxDw7p/FJKVuICk9w0+9nV0ugpBdvoiF7pheYaW+nPDfO6r8PZXfl7j2VYZPhTiHY7 BCtpfwx8pMg7fdvW+soBix8KV1ayQJAc9gkD0yczjKq5zrBGtTkiij1g; 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: 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 On Apr 2, 2007, at 10:14 AM, David Conrad wrote: > Good thing we don't need ARP. > > Routers already buffer. A somewhat common and successful router implementation used to drop all transit packets that required ARP requests. Doing otherwise requires possibly unbounded storage requirements and simplifies DoS attacks. Buffering user packets to cover mapping delay will have the same impact and be fundamentally unsolvable (modulo some LRU techniques) unless the mapping is very highly distributed, preferably co-located in the host itself. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:39:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQVG-0007CL-6N; Mon, 02 Apr 2007 13:39:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQVF-0007C6-B7 for ram@iab.org; Mon, 02 Apr 2007 13:39:37 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQVD-0007Bx-Rw for ram@iab.org; Mon, 02 Apr 2007 13:39:37 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 10:39:35 -0700 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 l32HdZ0g027680; Mon, 2 Apr 2007 10:39:35 -0700 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 l32HdZwn020368; Mon, 2 Apr 2007 17:39:35 GMT 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); Mon, 2 Apr 2007 10:39:34 -0700 Received: from [192.168.0.100] ([10.21.80.188]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:39:34 -0700 In-Reply-To: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@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: <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 10:39:42 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:39:34.0419 (UTC) FILETIME=[E095BE30:01C7754D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=763; t=1175535575; x=1176399575; c=relaxed/simple; s=sjdkim8002; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP] |Sender:=20; bh=IKmepGJdTHs6rBWoHcqUjSIBOQaWfzZW7HAf81q3g8M=; b=lrDp50Sz5g3BY8VL2YyWL+lJPohjWMbdH6zGyJw+R0PytWwQZfOdlFNg9qoV/o7RLVgdsL+/ iyE8POcPGOAFeGq9rwysiiRiM5sP9zb2WaaOpYmB7vtXww8TMztZI5GW; Authentication-Results: sj-dkim-8; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: "Fleischman, Eric" , 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 Apr 2, 2007, at 9:56 AM, Dino Farinacci wrote: >> But I think we need to design the locator mapping service to deal >> with the worst case; if that is really 10M entries I am not too >> frightened. It isn't the same problem as 10M DFZ routes. > > I am actually not worried about the aggregateability of the EID- > prefix space. Since it will be based on an allocation hierarchy and > not a topology heirarchy. > > What I do worry about is the locator-set placement which can cause > deaggregateability of the allocated EID-prefix block. Aggregate-ability of locators is wholly irrelevant in a push model, since the entire database must be distributed anyway. Have we converged on only using a pull model for the mapping? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:39:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQVU-0007NL-Ja; Mon, 02 Apr 2007 13:39:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQVT-0007ND-0g for ram@iab.org; Mon, 02 Apr 2007 13:39:51 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQVQ-0007DH-Bt for ram@iab.org; Mon, 02 Apr 2007 13:39:50 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 10:39:48 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l32Hdl8k029270 for ; Mon, 2 Apr 2007 10:39:47 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32HdlA8016683 for ; Mon, 2 Apr 2007 17:39:47 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:40:09 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=532; t=1175535587; x=1176399587; c=relaxed/simple; s=sjdkim6002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=am20Yz5mZ35VBeqYu3GMUg+i32fjEVw9oHGiC7X+iIM=; b=g80te5uNZr62QaVxNdXuzB+tDA+/3r80KscC5vcbjCBL6qj3C82qRDU9DbDzPiPMKlqHcZDq mvGLz61Vo4xujeHxrsMYwSDGg1KJvfVmJG5rFpOlDsZymyepvjkoIBbl; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Apr 2, 2007, at 10:16 AM, Fleischman, Eric wrote: > IPv6 represents an expense for the end user but does not offer any > functionality to justify that expense -- there is no killer app for > IPv6. The only caveat I would add is spimes/supply-chain/mobility/DCN address exhaustion. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:41: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 1HYQWo-00085N-Pq; Mon, 02 Apr 2007 13:41:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQWo-00085I-46 for ram@iab.org; Mon, 02 Apr 2007 13:41:14 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQWm-0007OQ-SA for ram@iab.org; Mon, 02 Apr 2007 13:41:14 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 10:41:12 -0700 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 l32HfC7a028640 for ; Mon, 2 Apr 2007 10:41:12 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32HfCwn021117 for ; Mon, 2 Apr 2007 17:41:12 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8CDA0E9C-2318-4F7E-A3BB-D8B5549C1C2C@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:41:33 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=571; t=1175535672; x=1176399672; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=LtXkTa2q7s7RtMDf6v2STBEKBZmkKOcUwblC6CtyFho=; b=vsgLZrxQj8BJ6FT7mqgf1lrsaHaiSpvwLF1A0ZwEODF0ZpXFF/afxSv+rgBGAVR1Zmlq+7wQ WiyU3fXRbPM/Wrxir7kTtLPU3XIkXhUoY3RVbrERVK9qEoIQlWuWZd+8; 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: de4f315c9369b71d7dd5909b42224370 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 Apr 2, 2007, at 10:22 AM, Dino Farinacci wrote: > So question to beg is will IT managers feel comfortable pointing > DNS server addresses to this map-n-encap routers. I don't think the network operations staff will necessarily be overjoyed with this new responsibility, and it also strikes me as a great DoS vector. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:42:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQY5-00007W-C9; Mon, 02 Apr 2007 13:42:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQY4-00007R-Hg for ram@iab.org; Mon, 02 Apr 2007 13:42:32 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQY3-0007X6-93 for ram@iab.org; Mon, 02 Apr 2007 13:42:32 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 10:42:30 -0700 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 l32HgUL8020280 for ; Mon, 2 Apr 2007 10:42:30 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32HgUA8018286 for ; Mon, 2 Apr 2007 17:42:30 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:42:51 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=536; t=1175535750; x=1176399750; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=ueL47pE+e61lkGxL/rLiB4qlQiBmyyjd7QQZJIVFFkU=; b=f4QJDIGsphOtvGJOId001TZBqMru3Tare0MbBskuLOv7SVD2I40hBMVyvCwbeH1YpSs1FgAn SxiCwm/pnHZ6uPc+mAyD1IFABt+hxezRBsRlaOOH/3Qrb8EVu+dSO5m+; 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: de4f315c9369b71d7dd5909b42224370 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 Apr 2, 2007, at 10:23 AM, David Conrad wrote: > As lots of people pointed out lots of times, the size of the > address wasn't really the problem, rather the scalability of the > routing system was. The address-space issue is more pertinent today than it was when CIDR was posited. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:44:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQZi-0002vT-Jd; Mon, 02 Apr 2007 13:44:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQZh-0002sF-8M for ram@iab.org; Mon, 02 Apr 2007 13:44:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQZf-00083p-Us for ram@iab.org; Mon, 02 Apr 2007 13:44:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 10:44:09 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32Hi9eK024006; Mon, 2 Apr 2007 10:44:09 -0700 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 l32Hi9MJ011092; Mon, 2 Apr 2007 17:44:09 GMT 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); Mon, 2 Apr 2007 10:44:04 -0700 Received: from [192.168.0.100] ([10.21.80.188]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:44:03 -0700 In-Reply-To: <461124DB.7010106@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.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: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:43:52 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:44:03.0888 (UTC) FILETIME=[81337300:01C7754E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=459; t=1175535849; x=1176399849; c=relaxed/simple; s=sjdkim1004; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=y9FoPXWt+tnTLqL40QxpRtkSqDr+M64AicX5hiAgvJs=; b=fqEIPD4XwGLFxmqnEyc0RRzJlayyapykiDQ1q0m89q6NCjCtOUkvlIWNex1dZNJf3axJDNuU i0bNNbzISM8rH9wfZFTXkgUeaK8EQ/ItR/DXOmNOGc1rqBnB+ZI6M1PdD2PGQXdDjlqeSurvdW WB3BuVY6WZ1uOyEMav3i5Ncm0=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Apr 2, 2007, at 8:44 AM, Eliot Lear wrote: > All I'm saying is that a router can't do an off box lookup. It's > just a non-starter (see below). Assuming a pull model, there's no real reason that a router can't implement a cache of mappings, even if the lookup is off-box. If you trigger the mapping based on a DNS request, as Fred has suggested, then the cache can be pre-populated before the first data packet arrives. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:45:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQar-000877-6C; Mon, 02 Apr 2007 13:45:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQaq-000871-96 for ram@iab.org; Mon, 02 Apr 2007 13:45:24 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQap-0008G4-1O for ram@iab.org; Mon, 02 Apr 2007 13:45:24 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Apr 2007 13:45:23 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32HjMVo031924 for ; Mon, 2 Apr 2007 13:45:22 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32HjMGf016020 for ; Mon, 2 Apr 2007 17:45:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:45:20 -0400 Received: from [192.168.0.4] ([10.82.209.169]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:45:20 -0400 In-Reply-To: <8CDA0E9C-2318-4F7E-A3BB-D8B5549C1C2C@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <8CDA0E9C-2318-4F7E-A3BB-D8B5549C1C2C@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <97FE084C-7994-4D3A-B5DA-3B3906FE5826@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:45:24 -0700 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 17:45:20.0460 (UTC) FILETIME=[AED768C0:01C7754E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=236; t=1175535922; x=1176399922; c=relaxed/simple; s=rtpdkim2001; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20 |To:=20Roland=20Dobbins=20; bh=h2n7GsO5uabpvku4hF+yvkFNXVl4YToO8mkHkNh3GAc=; b=hLXBFGHAmJPMu7Dy0rfZJCkO3LmxDifZcUggPiS97eQ/jKl4OQWium+zSZuPoo8LmoZIAD3p lzxLDY6rwk0v+6OrCd+eAtQ0UWU6DrTRiycPC1+RzI/udoFczwFcxgmI; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 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 don't think the network operations staff will necessarily be > overjoyed with this new responsibility, and it also strikes me as a > great DoS vector. The same DOS vector we have today to DNS servers or a new one? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:48:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQe0-0000uB-39; Mon, 02 Apr 2007 13:48:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQdy-0000u5-Qs for ram@iab.org; Mon, 02 Apr 2007 13:48:38 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQdx-0000Tg-79 for ram@iab.org; Mon, 02 Apr 2007 13:48:38 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32HYl61034563; Mon, 2 Apr 2007 10:34:48 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 10:48:24 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 10:48:24 -0700 In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:48:23 -0700 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Eric, On Apr 2, 2007, at 10:16 AM, Fleischman, Eric wrote: > From: Roger Jorgensen [mailto:rogerj@jorgensen.no] >> What has to be changed with IPv6 to avoid it being self-defeating? > > The architecture must not require widespread end user deployment in > order to work, as it currently does -- either that, or there must be a > truly compelling reason from the end user perspective for the end user > to want to support IPv6. Or perhaps, the architecture (and changes to that architecture) must be essentially transparent to the end user and their supporting organizations. > IPv6 was originally designed to solve ISP problems to which the end > user > has no visibility. Not really. IPv6 was designed to solve a political problem (namely, OSI and the ITU's assumption that it would control the future of data communications). Governments and industry were convinced the amount of address space represented by 32 bits was a problem and the IETF community needed a response to NSAPs. As far as I can tell, ISPs didn't really care all that much about the amount of address space. They still don't. What they appear to care about is minimizing cost of infrastructure and the big concern driving RAM is that the cost of providing that infrastructure may (there is still some argument) grow super-linearly. > IPv6 represents an expense for the end user but does not offer any > functionality to justify that expense -- there is no killer app for > IPv6. Until a killer app emerges, the end user is naturally > motivated to > avoid introducing non-value-added variability to their infrastructure > and thereby significantly increase their own operations and support > costs. To clarify, I'd argue that the vast majority of end users couldn't care less whether they had IPv4, IPv6, NSAPs, or lima beans for addresses. What end users care about is continued accessibility to network services of various flavors and kinds. Until this can be provided over IPv6, with no need for any significant end user (or end user supporting organization) configuration changes, IPv6 will remain dead in the water. > Worse yet, until IPv6 permitted PI addresses, it represented a > mechanism > that required large end users to be held captive to their ISPs. > This is > untenable to any end user and violates a fundamental law of economics > that businesses support the needs of their customers. Rather, the > model > originally used by IPv6 was that customers support the needs of their > vendors. Not!!! Yep. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:48:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQeH-00013q-KI; Mon, 02 Apr 2007 13:48:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQeG-00013j-KU for ram@iab.org; Mon, 02 Apr 2007 13:48:56 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQeF-0000W6-Bt for ram@iab.org; Mon, 02 Apr 2007 13:48:56 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32HmqKc027127 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 10:48:52 -0700 (PDT) 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 l32HmqWL013614; Mon, 2 Apr 2007 10:48:52 -0700 (PDT) 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 l32HmmPV013425; Mon, 2 Apr 2007 10:48:51 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:48:50 -0700 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] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:48:49 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EB5@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1TezkApgVUBN1SiKc9f0MEOFvvgAAB8vQ References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 02 Apr 2007 17:48:50.0851 (UTC) FILETIME=[2C3E8730:01C7754F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 >From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 >> IPv6 represents an expense for the end user but does not offer any=20 >> functionality to justify that expense -- there is no killer app for=20 >> IPv6. >The only caveat I would add is spimes/supply-chain/mobility/DCN address >exhaustion. That's why we have NAT. It's a sad state of affairs that NAT is cheaper and more practical for the end user today than IPv6 is.=20 Concerning IPv6 mobility, QoS, security, etc. (i.e., all of the claimed IPv6 technical advantages): Well, maybe if you are using Mobile IP there are some advantages -- but enough to justify a deployment??? Probably not. If you aren't using Mobile IP, then these claims are all fairly empty promises today. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:49:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQfF-0001Yc-Cu; Mon, 02 Apr 2007 13:49:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQfD-0001YX-Sv for ram@iab.org; Mon, 02 Apr 2007 13:49:55 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQfC-0000YP-KZ for ram@iab.org; Mon, 02 Apr 2007 13:49:55 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 10:49:54 -0700 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 l32HnsPl024602 for ; Mon, 2 Apr 2007 10:49:54 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32Hnrwn028868 for ; Mon, 2 Apr 2007 17:49:54 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:50:15 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=705; t=1175536194; x=1176400194; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=aY/tu5RLf48uSxMXPjWXdksuOuqSnMCf8W+5WhM8mkM=; b=tPxjc/sxB+CKdk4A3onXliKthLEPI8bwbGx3JRYZA1NHw1bajZlNDk1qhiLyeHvsm0TzmBwD xiJyBb5qSuipSFpRWZPaVim6h+8V4nWaXrQNnBHGKRGFa7pupBZ5lta8; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Apr 2, 2007, at 10:43 AM, Tony Li wrote: > Assuming a pull model, there's no real reason that a router can't > implement a cache of mappings, even if the lookup is off-box. If > you trigger the mapping based on a DNS request, as Fred has > suggested, then the cache can be pre-populated before the first > data packet arrives. What about IP communications which don't involve DNS lookups? A fair amount of VoIP is done this way, for example. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:57:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQm6-0002yu-6G; Mon, 02 Apr 2007 13:57:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQm5-0002yp-3d for ram@iab.org; Mon, 02 Apr 2007 13:57:01 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQm3-000231-Qw for ram@iab.org; Mon, 02 Apr 2007 13:57:01 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 10:57:00 -0700 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 l32Hux1R007581 for ; Mon, 2 Apr 2007 10:56:59 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32HuvA8026935 for ; Mon, 2 Apr 2007 17:56:59 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <97FE084C-7994-4D3A-B5DA-3B3906FE5826@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <8CDA0E9C-2318-4F7E-A3BB-D8B5549C1C2C@cisco.com> <97FE084C-7994-4D3A-B5DA-3B3906FE5826@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <952390EB-5FC8-435B-8352-87763782FD41@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 10:57:18 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1375; t=1175536619; x=1176400619; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=JMx3ywXlm7xFhRh2/JwR6RptFvGhxffP34b42XSWw94=; b=xKIODBJa5i/zmIN005Xb30DLb4joGyhQ3wErIMzrXcFsMTna+fX1aYE/xuzIqoxe81k4V8gu 6PL3kCQDjtnaFcz4Ek02oNp3AZTdaX/jYhbRD/9DWKWQC3/Cb59TXOUP; 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: 8abaac9e10c826e8252866cbe6766464 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 Apr 2, 2007, at 10:45 AM, Dino Farinacci wrote: > The same DOS vector we have today to DNS servers or a new one? Mostly the same ones, with the added bonus that they can now potentially disrupt routing. And of course this scheme is going to involve a pretty substantial increase in the number of DNS lookups, as well. Not to mention the face that, absent universal DNSSEC deployment, the potential for other forms of abuse could well increase if we rely on the DNS for this lookup functionality. Why all the interest in the DNS for this? Why not just do it in the routing protocols or in some fancy new in-band (from the point of the network infrastructure) mechanism? DNS wasn't designed to do this, and the global DNS won't scale for this/isn't reliable enough for this/isn't politically or operationally feasible for this; so now we want to collapse DNS functionality into the routers? Without rehashing all the same arguments, it appears that a pretty good case has been made that the DNS isn't right for this application. Which seems to indicate the need for Something Else. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 13:59:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQoO-0003XG-7y; Mon, 02 Apr 2007 13:59:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQoN-0003XB-Eo for ram@iab.org; Mon, 02 Apr 2007 13:59:23 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQoL-0002gM-Rd for ram@iab.org; Mon, 02 Apr 2007 13:59:23 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32HxLo6004987 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 10:59:21 -0700 (PDT) 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 l32HxKjo012040; Mon, 2 Apr 2007 10:59:20 -0700 (PDT) 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 l32HxGxZ011835; Mon, 2 Apr 2007 10:59:20 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 10:59:19 -0700 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] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 10:59:18 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1TyKFelMvHRmeRDy/BC7ZnMj7/wAAChNw References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> From: "Fleischman, Eric" To: X-OriginalArrivalTime: 02 Apr 2007 17:59:19.0437 (UTC) FILETIME=[A2E923D0:01C77550] 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 >From: David Conrad [mailto:drc@virtualized.org]=20 >> The architecture must not require widespread end user deployment in=20 >> order to work, as it currently does -- either that, or there must be a=20 >> truly compelling reason from the end user perspective for the end user=20 >> to want to support IPv6. >Or perhaps, the architecture (and changes to that architecture) must=20 >be essentially transparent to the end user and their supporting organizations. Yes!!! I fully agree. LISP offers this promise. Whatever the IETF finally chooses also needs to do this, if we are going to finally have a realistic (non-mythical) architecture. >To clarify, I'd argue that the vast majority of end users couldn't=20 >care less whether they had IPv4, IPv6, NSAPs, or lima beans for=20 >addresses. What end users care about is continued accessibility to=20 >network services of various flavors and kinds. Until this can be=20 >provided over IPv6, with no need for any significant end user (or=20 >end user supporting organization) configuration changes, IPv6 will=20 >remain dead in the water. I agree except for those situations where a powerful political force decrees that IPv6 will be deployed. In those situations, the OSI historical precedent showed that OSI was indeed deployed -- in the most minimal fashion permitted by the powerful decrees. OSI was primarily deployed in real life in niche environments (e.g., Aeronautical Telecommunications Networks, electrical industry, ...). =20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:00:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQp7-0003hG-MT; Mon, 02 Apr 2007 14:00:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQp6-0003gg-Mi for ram@iab.org; Mon, 02 Apr 2007 14:00:08 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQp5-0002s6-EX for ram@iab.org; Mon, 02 Apr 2007 14:00:08 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 11:00:08 -0700 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 l32I06qa032433 for ; Mon, 2 Apr 2007 11:00:06 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32I06wn004373 for ; Mon, 2 Apr 2007 18:00:06 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EB5@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB5@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <9D1B532F-D027-40DE-8BB4-D15AFE34FF3A@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 11:00:28 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=635; t=1175536806; x=1176400806; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=euLaLGB9jDsBMZdUQSb3qGxBfJBfw3+Qou33L2GHkvk=; b=b0mG6T4wohE0R8qTpIacSDlcd35VL7u9BZ8pMyYmF6v0S/KddMspdn1jjnTgwm/NGbKlSQ+a KUGu5FPkdtcgCJkHDCNj5FupVY1VewTgqdmPWNYjcVVYQY88DGJXwnLK; 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 2, 2007, at 10:48 AM, Fleischman, Eric wrote: > That's why we have NAT. It's a sad state of affairs that NAT is > cheaper > and more practical for the end user today than IPv6 is. NAT doesn't scale for spimes, supply-chain, mobility, nor for DCNs, and it is too rigid for these applications, as well. Some SPs have deployed IPv6 on their DCNs because of this set of issues. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:01:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQqe-00047V-E3; Mon, 02 Apr 2007 14:01:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQqd-00047Q-EM for ram@iab.org; Mon, 02 Apr 2007 14:01:43 -0400 Received: from ug-out-1314.google.com ([66.249.92.175]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQqc-00046g-5c for ram@iab.org; Mon, 02 Apr 2007 14:01:43 -0400 Received: by ug-out-1314.google.com with SMTP id z36so10004uge for ; Mon, 02 Apr 2007 11:01:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=a+ttUDeXRO4tXrVCgeWEFS2IwWCZEgeTOhKUQTLDntQv0pTH+fHTblOz0j1TgmKc98LXcOUcBJW2p0q1n0uPwqWKNdSs1PQVIvT4lWWcNXrGWcBUcpJjQ1wU8z6HA762NpWUP74OoZSy6HNq01X/dgXCsSABSxcuMnd+nkUfEWg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gcp6FmhKOJbp7byOsyTQPqDfCiObmCmxdoU1enAZArm/dQNtfnwLHBoVe+ahvlOnbw8IyQalrX5PikwQVEfMhjX5cgdDamIEAmMv0wQFGKJ/UvS7yIX4+FBHY5F4eeIbuC5iHA5wslbx4MBg3Rt0X+My5HdmdEWJp+gq8pj+Hww= Received: by 10.82.102.4 with SMTP id z4mr8238283bub.1175536898105; Mon, 02 Apr 2007 11:01:38 -0700 (PDT) Received: by 10.82.111.17 with HTTP; Mon, 2 Apr 2007 11:01:37 -0700 (PDT) Message-ID: Date: Mon, 2 Apr 2007 21:01:37 +0300 From: McTim To: "Roland Dobbins" Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 4/2/07, Roland Dobbins wrote: > > > What about IP communications which don't involve DNS lookups? A fair > amount of VoIP is done this way, for example. Won't this change significantly with more widespread ENUM usage? -- Cheers, McTim $ whois -h whois.afrinic.net mctim _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:02:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQrS-0004vl-SH; Mon, 02 Apr 2007 14:02:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQrR-0004vg-TF for ram@iab.org; Mon, 02 Apr 2007 14:02:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQrQ-0004pT-Kx for ram@iab.org; Mon, 02 Apr 2007 14:02:33 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 11:02:32 -0700 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 l32I2Ww8012656 for ; Mon, 2 Apr 2007 11:02:32 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32I2Vwn006203 for ; Mon, 2 Apr 2007 18:02:32 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1B6DB1E4-2776-49B6-9F13-BE25119D1CC4@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 11:02:53 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=722; t=1175536952; x=1176400952; c=relaxed/simple; s=sjdkim6002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=kTIh+kQlK9KklOIiv0ruhTRRhmI7iJ30pIBQIFPgcoA=; b=dHY5k/mvZ9pT5U4kzbpZqJHkFs2uDxERqabKo4KBr8XoogbIl3ERwtL60IXG5t2xrQbAp18G M1dlyvftDyVKCakN6zsCX1hk201LosmyJ6/89l1gM5boOjuz290VYowH; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Apr 2, 2007, at 10:48 AM, David Conrad wrote: > Not really. IPv6 was designed to solve a political problem > (namely, OSI and the ITU's assumption that it would control the > future of data communications). Governments and industry were > convinced the amount of address space represented by 32 bits was a > problem and the IETF community needed a response to NSAPs. It has been said in some quarters that IPv6 is can be viewed as 'GOSIP Strikes Back'. ;> ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:04:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQsv-0007ji-P7; Mon, 02 Apr 2007 14:04:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQsv-0007jd-3T for ram@iab.org; Mon, 02 Apr 2007 14:04:05 -0400 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 1HYQst-0005u2-Pb for ram@iab.org; Mon, 02 Apr 2007 14:04:05 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32I42je000949 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 13:04:02 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l32I42lZ027678; Mon, 2 Apr 2007 13:04:02 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l32I416V027617; Mon, 2 Apr 2007 13:04:02 -0500 (CDT) 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); Mon, 2 Apr 2007 11:03:59 -0700 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] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:03:58 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acd1S59AR/xPWskIQc2clvuQIjHwdQABVvsg References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" , "David Conrad" X-OriginalArrivalTime: 02 Apr 2007 18:03:59.0956 (UTC) FILETIME=[4A1CF140:01C77551] X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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'll add to what Dino said that everything works best when the host, the DNS server and the ITR all occur on the same physical platform (or, "enclave" as some call it). Fred fred.l.templin@boeing.com > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Monday, April 02, 2007 10:23 AM > To: David Conrad > Cc: ram@iab.org > Subject: Re: [RAM] Incremental Deployment of LISP >=20 > > On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: > >>> [latency] > >> Because we shouldn't engineer delay into the system, > > > > There are already numerous delays engineered into the system. >=20 > David, let me try this to see how Eliot will react. >=20 > Eliot, (like Fred Templin's idea), what if the host pointed it's DNS =20 > server address to a router, say the ITR router. >=20 > So when the host does a DNS lookup, the router intercepts it (not =20 > really intercepts it because the UDP packet is addressed to the =20 > router), sends it on but also adds a request record for say a RLOC =20 > RR. The ITR will have to make the request come from the ITR's source =20 > address so the reply returned can get the RLOC RR stored in the EID-=20 > to-RLOC mapping cache by the ITR. Then the ITR can return the A =20 > record reply to the host. >=20 > All this happens before the first TCP SYN is sent by the host. >=20 > There is increased latency, but the host doesn't really know any =20 > differently. >=20 > So question to beg is will IT managers feel comfortable pointing DNS =20 > server addresses to this map-n-encap routers. >=20 > Dino >=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 Apr 02 14:05:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQty-0000tR-FN; Mon, 02 Apr 2007 14:05:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQtw-0000tM-2m for ram@iab.org; Mon, 02 Apr 2007 14:05:09 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQtu-0006Nz-Qr for ram@iab.org; Mon, 02 Apr 2007 14:05:08 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 11:05:06 -0700 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 l32I56Rb003353 for ; Mon, 2 Apr 2007 11:05:06 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32I56A8001575 for ; Mon, 2 Apr 2007 18:05:06 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <43583DB9-39B0-44D3-8ACA-9503B87B99BD@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:05:27 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=585; t=1175537106; x=1176401106; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=M/2rtzY3oS8F9dQiieFTx4Gs3jcPLoVP/WxzHf8WA+s=; b=ecg4RvXrHrwLXmVBmz6+0hcFuAftkkrULIBB49HIW5yRC5+RMfA7tsH8psgdpjSEfZZRZOBz V4gK0JAH8fEvP9dNH29AhC896TiSEYrzJYGY4DYqZZYRzrWT/p1TQfH9; 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: de4f315c9369b71d7dd5909b42224370 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 Apr 2, 2007, at 11:01 AM, McTim wrote: > Won't this change significantly with more widespread ENUM usage? In some cases, yes, assuming ENUM is in fact widely deployed. In the case of various semi-closed proprietary overlay systems (such as many of the more popular ones in use today), it's not clear that this would be the case. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:05:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQuE-0001Mg-Rg; Mon, 02 Apr 2007 14:05:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQuD-0001MW-Bk for ram@iab.org; Mon, 02 Apr 2007 14:05:25 -0400 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 1HYQuB-0006Zt-44 for ram@iab.org; Mon, 02 Apr 2007 14:05:25 -0400 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 l32I5L8b002241 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 13:05:22 -0500 (CDT) 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 l32I5KlS023887; Mon, 2 Apr 2007 11:05:21 -0700 (PDT) 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 l32I5DDP023461; Mon, 2 Apr 2007 11:05:18 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 11:05:13 -0700 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] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 11:05:13 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584EB7@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <9D1B532F-D027-40DE-8BB4-D15AFE34FF3A@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1UMNcSIs7/3kHR7CXDyWg8T7a9gAABn+Q References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EB5@XCH-NW-6V1.nw.nos.boeing.com> <9D1B532F-D027-40DE-8BB4-D15AFE34FF3A@cisco.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 02 Apr 2007 18:05:13.0910 (UTC) FILETIME=[76316D60:01C77551] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 >From: Roland Dobbins [mailto:rdobbins@cisco.com]=20 >> That's why we have NAT. It's a sad state of affairs that NAT is=20 >> cheaper and more practical for the end user today than IPv6 is. >NAT doesn't scale for spimes, supply-chain, mobility, nor for DCNs,=20 >and it is too rigid for these applications, as well. Some SPs have=20 >deployed IPv6 on their DCNs because of this set of issues. Supply chain -- lots of examples of NATs Mobility -- depends on the architecture. MONETs have been deployed using NATs. Rigid? If you say so, though the number of deployments suggests that rigidity is being somehow overcome. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:07:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQvo-0002Qn-Kz; Mon, 02 Apr 2007 14:07:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQvn-0002Qi-6J for ram@iab.org; Mon, 02 Apr 2007 14:07:03 -0400 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 1HYQvl-0006zH-TY for ram@iab.org; Mon, 02 Apr 2007 14:07:03 -0400 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 l32I71sL001339 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 11:07:01 -0700 (PDT) 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 l32I70cf001403; Mon, 2 Apr 2007 11:07:00 -0700 (PDT) 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 l32I6sqL001125; Mon, 2 Apr 2007 11:06:59 -0700 (PDT) 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); Mon, 2 Apr 2007 11:06:51 -0700 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: Thousands of large PI customers [Re: [RAM] IncrementalDeploymentof LISP] Date: Mon, 2 Apr 2007 11:06:50 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774874@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thousands of large PI customers [Re: [RAM] IncrementalDeploymentof LISP] Thread-Index: Acd1TegvqDKpLZV7Q26j3MWY+vb1iQAA56wg References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><4610C965.8010208@zurich.ibm.com><474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com><4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> From: "Templin, Fred L" To: "Tony Li" , "Dino Farinacci" X-OriginalArrivalTime: 02 Apr 2007 18:06:51.0568 (UTC) FILETIME=[B066DB00:01C77551] X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Fleischman, Eric" , 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 Tony, =20 > Have we converged on only using a pull model for the mapping? By "pull", do you mean the LISP 2/3 model instead of LISP1/1.5? If so, I agree. Fred fred.l.templin@boeing.com =20 > 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 Mon Apr 02 14:10: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 1HYQyU-00053n-OS; Mon, 02 Apr 2007 14:09:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYQyT-000508-7t for ram@iab.org; Mon, 02 Apr 2007 14:09:49 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYQyR-0007ug-VS for ram@iab.org; Mon, 02 Apr 2007 14:09:49 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 11:09:48 -0700 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 l32I9lcK016870 for ; Mon, 2 Apr 2007 11:09:47 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32I9lwn009695 for ; Mon, 2 Apr 2007 18:09:47 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EB7@XCH-NW-6V1.nw.nos.boeing.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EB5@XCH-NW-6V1.nw.nos.boeing.com> <9D1B532F-D027-40DE-8BB4-D15AFE34FF3A@cisco.com> <474EEBD229DF754FB83D256004D0210802584EB7@XCH-NW-6V1.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 11:10:06 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=758; t=1175537387; x=1176401387; c=relaxed/simple; s=sjdkim6002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=LzyYCoMD8VMknR+1WTQ8yEw/zenkCXKNTyvfntpZsf4=; b=jUWhsCU2GywHsHQeq/hL28SgvdwEmMoteFZ0dZK43CuRpPys9X5NhoaP8nq03yyQu+dJUOOJ ZlVX3bGmxCn5z0q597nkdyhl7C9Rg6Td6X1ZEzlOTRIsbplbFyIGZazX; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Apr 2, 2007, at 11:05 AM, Fleischman, Eric wrote: > If you say so, though the number of deployments suggests that > rigidity is being somehow overcome. NATs are by definition topologically static. When the soda can leaves the factory, is trucked to the grocery store, is put on another truck, and then delivered into my refrigerator, it seems to me that I can't reasonably expect all those various supply-chain networks (including one in my flat called the Internet) to be appropriately NATted. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:18:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR6f-00032b-C0; Mon, 02 Apr 2007 14:18:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR6d-00032W-UX for ram@iab.org; Mon, 02 Apr 2007 14:18:15 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYR6c-0003l0-LM for ram@iab.org; Mon, 02 Apr 2007 14:18:15 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 20:18:15 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32IIDO8002134; Mon, 2 Apr 2007 20:18:13 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp406.cisco.com [10.61.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32IIDlZ029647; Mon, 2 Apr 2007 18:18:13 GMT Message-ID: <461148E3.9090001@cisco.com> Date: Mon, 02 Apr 2007 20:18:11 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> In-Reply-To: <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1237; t=1175537894; x=1176401894; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=/niahYwl1lgm1VTR5KJZ1BQ9Zkp+rXMhZPMI+FH3ySA=; b=bjBhU1ygy05IRtxs4P11peE1dTKxSD5hvXDXF8sSlDwf6d5lJM7Zmjks9naODVsoAJN4UCkL NxUt7xyprm4St5dXi2qGVepBJKnnx+BbpoTGiYcKdRZ1Q3P3+Tcp093t; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 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 Dino Farinacci wrote: >> On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: >>>> [latency] >>> Because we shouldn't engineer delay into the system, >> >> There are already numerous delays engineered into the system. > > David, let me try this to see how Eliot will react. > > Eliot, (like Fred Templin's idea), what if the host pointed it's DNS > server address to a router, say the ITR router. > > So when the host does a DNS lookup, the router intercepts it (not > really intercepts it because the UDP packet is addressed to the > router), sends it on but also adds a request record for say a RLOC RR. > The ITR will have to make the request come from the ITR's source > address so the reply returned can get the RLOC RR stored in the > EID-to-RLOC mapping cache by the ITR. Then the ITR can return the A > record reply to the host. > > All this happens before the first TCP SYN is sent by the host. > > There is increased latency, but the host doesn't really know any > differently. The host knows when the conversation will start, and buffering the latency in the host is far more practical because it can react better if it doesn't like it. This is HIP, btw. I have no problems with it. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:18:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR6z-0003Ol-To; Mon, 02 Apr 2007 14:18:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR6z-0003Og-6W for ram@iab.org; Mon, 02 Apr 2007 14:18:37 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYR6x-0003vV-U3 for ram@iab.org; Mon, 02 Apr 2007 14:18:37 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 20:18:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32IIZG5020869; Mon, 2 Apr 2007 20:18:35 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp406.cisco.com [10.61.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32IIYlZ029706; Mon, 2 Apr 2007 18:18:35 GMT Message-ID: <461148F8.4050804@cisco.com> Date: Mon, 02 Apr 2007 20:18:32 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=224; t=1175537915; x=1176401915; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=WI1MHi9Mm6JI/xI/l/J1aPcoZyNbetuTbc+1V3R73Ew=; b=LaRQUO/k0dQ8dLjYQjWPDk0TiQKhSh2COzmAjBSVGQr6V2qb0fXfSRL6FIl/VryB42fbZbZh rv0/VD0pdkh6NVdeR112JetiKVScqu/98uyH3WULomDds0p9F+oZJ5jH; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 Dave, > Name one application that can't tolerate a delay on initial start up. False assumption from the get go. Why do you think it's only at the startup of the application? How is a *router* to know this? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:21:22 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR9I-0004t0-Un; Mon, 02 Apr 2007 14:21:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYR9I-0004sv-52 for ram@iab.org; Mon, 02 Apr 2007 14:21:00 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYR9G-0004th-Jx for ram@iab.org; Mon, 02 Apr 2007 14:21:00 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 20:20:59 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32IKvUW021192; Mon, 2 Apr 2007 20:20:57 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp406.cisco.com [10.61.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32IKvlZ000016; Mon, 2 Apr 2007 18:20:57 GMT Message-ID: <46114987.2060802@cisco.com> Date: Mon, 02 Apr 2007 20:20:55 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=490; t=1175538058; x=1176402058; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=/1pbM8cSDx03Dgwn/wFb7ulkNiMaxqswVX4J1iC4TyU=; b=VVlZltIINuDc+OJZh6+pqpCSdBf67CfuHuVY6fNq/tTc66Fd/3oe0rtzwHMTdhL+maydW5fe 5zuQb8XBOFTNHV6a2DdReDRVDmkGKjk/Umzfg6/m0xJozHK/Llk1KVNg; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Tony Li wrote: > > Assuming a pull model, there's no real reason that a router can't > implement a cache of mappings, even if the lookup is off-box. If you > trigger the mapping based on a DNS request, as Fred has suggested, > then the cache can be pre-populated before the first data packet arrives. > I think the only issue is how the router knows all of this under LISP. As long as it doesn't need to know that "an application is starting" I think that's fine. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:26:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRDj-0000bL-J2; Mon, 02 Apr 2007 14:25:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRDi-0000bF-Da for ram@iab.org; Mon, 02 Apr 2007 14:25:34 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRDf-0006Ic-W6 for ram@iab.org; Mon, 02 Apr 2007 14:25:34 -0400 Received: from [10.51.201.195] (vs1.ntta.com [207.198.160.6]) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l32IPBBW042702 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 2 Apr 2007 14:25:12 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <08FEEA3E-FE05-4076-81F5-F539653F62A9@lugs.com> Content-Transfer-Encoding: 7bit From: Peter Schoenmaker Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Mon, 2 Apr 2007 14:25:06 -0400 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Mon, 02 Apr 2007 14:25:13 -0400 (EDT) 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 On Mar 31, 2007, at 12:23 PM, Tony Li wrote: > > On Mar 31, 2007, at 2:22 AM, marcelo bagnulo braun wrote: > >> i think this is one fundamental part of the puzzle that is lacking >> in all available solutions > > > I'm not yet convinced that this is really a requirement. Consider > what you're asking: the ability to TE on a per-site basis, given > that traffic is already assigned to PA prefixes. Typically in the > past, ISPs have wanted to do TE within another providers prefix, > and thus we have more specifics. This is incredibly important for > managing peering ratios and the like. However, applying TE on > multi-homed PI sites seems like it would be much less important > requirement. > > Am I confused? Any operators in the forum, please speak up... For the case of multihomed end sites the weighting in the mapping lookup should be sufficient for TE. The requirements are fairly simple. For the case of TE between ISPs, the TE requirements are more complicated. Hot potato vs cold potato. Which adjacent AS to prefer, and which link to an adjacent as to use. peter > > 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 Mon Apr 02 14:27:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRFl-0001MD-FU; Mon, 02 Apr 2007 14:27:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRFk-0001M4-6u for ram@iab.org; Mon, 02 Apr 2007 14:27:40 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRFh-0006qN-44 for ram@iab.org; Mon, 02 Apr 2007 14:27:40 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32IDh61034697; Mon, 2 Apr 2007 11:13:44 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 11:27:20 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 11:27:20 -0700 In-Reply-To: <952390EB-5FC8-435B-8352-87763782FD41@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <8CDA0E9C-2318-4F7E-A3BB-D8B5549C1C2C@cisco.com> <97FE084C-7994-4D3A-B5DA-3B3906FE5826@cisco.com> <952390EB-5FC8-435B-8352-87763782FD41@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:27:17 -0700 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 Roland, On Apr 2, 2007, at 10:57 AM, Roland Dobbins wrote: > Why all the interest in the DNS for this? Personally, I typically use the DNS merely as an example of a pull- based model. It has many of the attributes we'd probably like to have if we go this route, from caching semantics to security (of a sort). I'd be happy with an alternative pull-based mechanism. However, with that said: > Why not just do it in the routing protocols or in some fancy new in- > band (from the point of the network infrastructure) mechanism? There is nothing stopping us from coming up with an entirely new protocol, other than perhaps time. We know where the DNS's warts are. When you come up with a new protocol, you usually have to spend a bit of time discovering its warts. > DNS wasn't designed to do this, The DNS was designed to be a fairly generic network based key/value lookup system. The lookup of a locator value given an identifier key is well within the model PVM had in mind (so he says) when he proposed the DNS protocol. > and the global DNS won't scale for this/isn't reliable enough for > this/isn't politically or operationally feasible for this; Irrelevant. We're talking about the DNS protocol, not necessarily the DNS as it has been implemented. However, with that said: - the global DNS has scaled to 60,000,000 names in a single zone and I have personal experience with implementations that can deal with an order of magnitude more. - the reliability of the DNS depends on its implementation from the root down the specific branch the series of labels you are interested in reside. The root is extremely reliable. There is nothing indicating a specific branch of the root can't be equally or more reliable. - politics aren't an issue since presumably, any sort of tree used for this sort of functionality would be found in the .ARPA TLD which is defined by the IAB - operationally, there exist over 100,000,000 names in the DNS. It would seem to be operationally feasible. It is worth noting that the DNS protocol is used both for ENUM (public and infrastructure) as well as for RFID, both of which have scaling and reliability characteristics beyond what is found in the existing DNS. > so now we want to collapse DNS functionality into the routers? What is being discussed is a way of on-demand fetching a mapping. The DNS protocol can be used for this function, but it doesn't have to be. However, if it isn't, you're going to have to solve many of the problems the DNS has solved. > Without rehashing all the same arguments, it appears that a pretty > good case has been made that the DNS isn't right for this > application. Which seems to indicate the need for Something Else. Propose something. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:31:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRJ1-0003U4-Mj; Mon, 02 Apr 2007 14:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRJ1-0003Tz-8Q for ram@iab.org; Mon, 02 Apr 2007 14:31:03 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRIz-0008Ae-Qb for ram@iab.org; Mon, 02 Apr 2007 14:31:03 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32IHL61034709; Mon, 2 Apr 2007 11:17:22 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 11:30:58 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 11:30:58 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:30:56 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Fred, On Apr 2, 2007, at 11:03 AM, Templin, Fred L wrote: > I'll add to what Dino said that everything works best when > the host, the DNS server and the ITR all occur on the same > physical platform (or, "enclave" as some call it). I'd agree with "DNS server" and "ITR", however assuming the DNS server has to be numbered out of locator space instead of identifier space, putting the host on the same physical platform means you lose one of the big advantages of ID/LOC separation: the ability to transparently "renumber". There is a tradeoff there, on one hand, the larger the scope of identifier addressability, the less impact a renumbering event has. On the other hand, the smaller the scope of identifier addressability, the more fine grained the control in stuff like multi-homing policy. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:32:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRKU-0004sF-Dg; Mon, 02 Apr 2007 14:32:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRKS-0004sA-Dw for ram@iab.org; Mon, 02 Apr 2007 14:32:32 -0400 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 1HYRKP-0000fe-S8 for ram@iab.org; Mon, 02 Apr 2007 14:32:32 -0400 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 l32IWStC020939 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 13:32:29 -0500 (CDT) 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 l32IWSZ2025629; Mon, 2 Apr 2007 11:32:28 -0700 (PDT) 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 l32IWP4u025564; Mon, 2 Apr 2007 11:32:27 -0700 (PDT) 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); Mon, 2 Apr 2007 11:32:22 -0700 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] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:32:21 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774875@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acd1VKVF9+92l8CFSSu6v9k9lGdNeAAADt2w References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com><8CDA0E9C-2318-4F7E-A3BB-D8B5549C1C2C@cisco.com><97FE084C-7994-4D3A-B5DA-3B3906FE5826@cisco.com><952390EB-5FC8-435B-8352-87763782FD41@cisco.com> From: "Templin, Fred L" To: "David Conrad" , "Roland Dobbins" X-OriginalArrivalTime: 02 Apr 2007 18:32:22.0931 (UTC) FILETIME=[412A4E30:01C77555] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > > and the global DNS won't scale for this/isn't reliable enough for =20 > > this/isn't politically or operationally feasible for this; >=20 > Irrelevant. We're talking about the DNS protocol, not necessarily =20 > the DNS as it has been implemented. However, with that said: I said this before, but I'm not worried about scaling issues at all. This could be implemented by putting only FQDNs for ITRs in the global DNS and keeping FQDNs for services in site specific name resolution services. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:41:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRRo-0003sR-Iy; Mon, 02 Apr 2007 14:40:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRRn-0003sJ-Pg for ram@iab.org; Mon, 02 Apr 2007 14:40:07 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRRZ-0003J9-NP for ram@iab.org; Mon, 02 Apr 2007 14:40:07 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32IdmeT003315 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 11:39:49 -0700 (PDT) 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 l32Idm3i010664; Mon, 2 Apr 2007 11:39:48 -0700 (PDT) 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 l32IdfER010331; Mon, 2 Apr 2007 11:39:48 -0700 (PDT) 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); Mon, 2 Apr 2007 11:39:47 -0700 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] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:39:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774876@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acd1VRG4HknN4E6BRP6GhWtIcKatTwAADGCA References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> From: "Templin, Fred L" To: "David Conrad" X-OriginalArrivalTime: 02 Apr 2007 18:39:47.0218 (UTC) FILETIME=[49FB1F20:01C77556] 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 David, > On Apr 2, 2007, at 11:03 AM, Templin, Fred L wrote: > > I'll add to what Dino said that everything works best when > > the host, the DNS server and the ITR all occur on the same > > physical platform (or, "enclave" as some call it). >=20 > I'd agree with "DNS server" and "ITR", however assuming the DNS =20 > server has to be numbered out of locator space instead of identifier =20 > space, putting the host on the same physical platform means you lose =20 > one of the big advantages of ID/LOC separation: the ability to =20 > transparently "renumber". No; I'm assuming the {host/DNS server/ITR} could be deeply embedded within an enterprise/site and not necessarily with a globally routeable locator. The locator could be re-written as packets make their way out of the site and finally pop out with a globally routable locator when the packet emerges into the DFZ. So, it could go: ident->loc(L1)->loc(L2)-> ... ->loc(Ln)->loc(global) where "loc(Li)" are locators that are valid only within a local scope within the enterprise/site. Folks who are interested in this thread should really check out IPvLX (http://ipblx.net). Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:41:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRTS-0004Zy-OU; Mon, 02 Apr 2007 14:41:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRTR-0004Zt-E2 for ram@iab.org; Mon, 02 Apr 2007 14:41:49 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRTQ-0004JL-3q for ram@iab.org; Mon, 02 Apr 2007 14:41:49 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 02 Apr 2007 20:41:47 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l32IfljT024435; Mon, 2 Apr 2007 20:41:47 +0200 Received: from [212.254.247.5] (ams3-vpn-dhcp406.cisco.com [10.61.65.150]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l32IfllZ003198; Mon, 2 Apr 2007 18:41:47 GMT Message-ID: <46114E69.20901@cisco.com> Date: Mon, 02 Apr 2007 20:41:45 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2312; t=1175539307; x=1176403307; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=AIV/+jco/seJGSgac4jv2t4CLPWd1VbiwgLd1g1leHk=; b=TxoQkz6BD3x3tiPwe+7QzOsB6PTNdPtlt0d1nGzO5KA9LeioSb4aHsHNWxIUB0eZZ/PSf5Pn zUMwI3oCeSwjwyky2JFmepo+bwS898BMVCNz3rqqZTcj/XdkjZBx2fbX; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 David Conrad wrote: > Eliot, > > On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: >>> [latency] >> Because we shouldn't engineer delay into the system, > > There are already numerous delays engineered into the system. > >> and second, because that is what matches existing behavior today. > > How long does it take for a router that takes full routes when it > initially started to be able to forward packets? A system based on a > pull model would be able to avoid this delay. > >> Want to take a guess as to which applications need that 1ms and which >> don't? > > Why 1ms? Why not 10ms or 0.1ms? None of these numbers appear to be > backed up by any empirical evidence. Actually, this is my point. We have very little data in terms of what applications would be impacted, and so the best behavior we can have is the behavior we have today. Any variation from that requires understanding what those tradeoffs are going to be and I think that's a Hard Problem. However... > > In an ideal world, I would agree that it would be really nice to have > the entire mapping table local. However, I believe this simply won't > scale. You're moving the routing table thrash problem from a smallish > set of really well connected core routers down to every edge system > (for some value of the variable "edge"). You can "solve" this problem > somewhat by artificially constraining how frequently the table > changes, but you're the one who is saying we shouldn't engineer delays > into the system. I take your point that you are concerned about LISP scaling. I think there is work to do to show that it would, and in that respect I agree with those concerns. To be clear a mapping update offers no routing delay per-se. And the whole point of the exercise is to engineer something the provisioned mapping is relatively static while the routing table remains stable or improves on the performance curve over time. You seem to think that this mapping will be huge. I don't know. I guess that it will scale with the number of multihomed end points. I imagine that each entry in this table saves some space somewhere in the RIB. I further envision that either big multihomed enterprise h/w or PE h/w will perform the mapping. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:43:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRUY-0004uP-8K; Mon, 02 Apr 2007 14:42:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRUX-0004uG-67 for ram@iab.org; Mon, 02 Apr 2007 14:42:57 -0400 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 1HYRUO-00051P-9t for ram@iab.org; Mon, 02 Apr 2007 14:42:57 -0400 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 l32Iglf4025642 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 11:42:47 -0700 (PDT) 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 l32Igln8021916; Mon, 2 Apr 2007 11:42:47 -0700 (PDT) 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 l32Igh0P021702; Mon, 2 Apr 2007 11:42:47 -0700 (PDT) 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); Mon, 2 Apr 2007 11:42:47 -0700 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] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:42:46 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774877@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774876@XCH-NW-7V2.nw.nos.boeing.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acd1VRG4HknN4E6BRP6GhWtIcKatTwAADGCAAABTqrA= References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com><5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <39C363776A4E8C4A94691D2BD9D1C9A101774876@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "David Conrad" X-OriginalArrivalTime: 02 Apr 2007 18:42:47.0361 (UTC) FILETIME=[B55AC310:01C77556] 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 > Folks who are interested in this thread should really > check out IPvLX (http://ipblx.net). Umm - make that "http://ipvlx.net". Thanks - 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 Mon Apr 02 14:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRWy-0005Ow-CQ; Mon, 02 Apr 2007 14:45:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRWw-0005Ol-Dr for ram@iab.org; Mon, 02 Apr 2007 14:45:26 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRWv-0006dU-0f for ram@iab.org; Mon, 02 Apr 2007 14:45:26 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32IUY61034743; Mon, 2 Apr 2007 11:30:35 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 11:44:11 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 11:44:11 -0700 In-Reply-To: <461148F8.4050804@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <461148F8.4050804@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <283DFE02-6396-43B9-92B3-E6C6DEF1ADEC@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:44:10 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Eliot, On Apr 2, 2007, at 11:18 AM, Eliot Lear wrote: > Dave, >> Name one application that can't tolerate a delay on initial start up. > False assumption from the get go. I used bad terminology (I meant protocol), but fair enough. > Why do you think it's only at the startup of the application? Well, that's the most common time a new end point/locator mapping would be needed. > How is a *router* to know this? It, of course, doesn't. However, at some point, the router will see a packet with a destination end point identifier it hasn't seen before, at which point it would do need to do an off-box lookup. It can then buffer that packet until it receives a response or drop it on the floor, assuming the source will retransmit like any protocol that assumes it lives on a best effort datagram infrastructure. At that point, unless the router has been restarted or has run out of cache and had to reuse a cache slot, the router knows when it has seen a request for the same end point identifier. Assuming the mapping has a TTL, the router can refresh the entry before the TTL expires if it determines it is likely the mapping would be used again. Thus, the latency hit would occur only the first time the router sees the destination end point identifier or when the mapping has been dumped from the cache. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:49:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRah-0008Rj-6E; Mon, 02 Apr 2007 14:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRaf-0008Qw-MN for ram@iab.org; Mon, 02 Apr 2007 14:49:17 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRad-00011b-Bb for ram@iab.org; Mon, 02 Apr 2007 14:49:17 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 11:49:15 -0700 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 l32InEHB020689 for ; Mon, 2 Apr 2007 11:49:14 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32InAwn024742 for ; Mon, 2 Apr 2007 18:49:14 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <283DFE02-6396-43B9-92B3-E6C6DEF1ADEC@virtualized.org> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <461148F8.4050804@cisco.com> <283DFE02-6396-43B9-92B3-E6C6DEF1ADEC@virtualized.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <8DAC789F-339D-4096-9640-A6FFF0A5DDF1@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:49:32 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=612; t=1175539754; x=1176403754; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=Mc+J2LgSKw5aGvi6NbEUZHnuQSKB4Dfo8jTR2Fmbvl4=; b=gULGSDvF36b/79APVwe+hR3+lxkRCKMGaKpJMIUrafylAiPkDndcc9kHmprWmiYQd+PSB3m5 CKRauJpcTzumiqilyuV5GaEeOSEII8JJwY8X19Yh4eXc5nzPR7V9hBKN; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 2, 2007, at 11:44 AM, David Conrad wrote: > Thus, the latency hit would occur only the first time the router > sees the destination end point identifier or when the mapping has > been dumped from the cache. What about dynamism on the part of the destination endpoint and/or communications models which involve dynamic multiple destination endpoints? ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 14:57:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRiY-0007Y7-1U; Mon, 02 Apr 2007 14:57:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRiW-0007Xv-Fy for ram@iab.org; Mon, 02 Apr 2007 14:57:24 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRiV-0006S0-27 for ram@iab.org; Mon, 02 Apr 2007 14:57:24 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32Ihh61034796; Mon, 2 Apr 2007 11:43:43 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 11:57:20 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 11:57:20 -0700 In-Reply-To: <8DAC789F-339D-4096-9640-A6FFF0A5DDF1@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <461148F8.4050804@cisco.com> <283DFE02-6396-43B9-92B3-E6C6DEF1ADEC@virtualized.org> <8DAC789F-339D-4096-9640-A6FFF0A5DDF1@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <05C82078-1381-439E-A5D2-FED25FE40838@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 11:57:18 -0700 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Roland, On Apr 2, 2007, at 11:49 AM, Roland Dobbins wrote: >> Thus, the latency hit would occur only the first time the router >> sees the destination end point identifier or when the mapping has >> been dumped from the cache. > What about dynamism on the part of the destination endpoint and/or > communications models which involve dynamic multiple destination > endpoints? I assume mappings have a TTL like the DNS RRset TTL. As I said in the note you took this from: >> Assuming the mapping has a TTL, the router can refresh the entry >> before the TTL expires if it determines it is likely the mapping >> would be used again. Refreshing the mapping would handle the dynamism you're mentioning (if I understand the question). Since the TTL would be assigned by the destination owner (albeit likely clamped by policy by the source), high levels of dynamic behavior could be supported -- _much_ higher than would be reasonably possible in a push based model. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 15:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRy7-0000qo-P2; Mon, 02 Apr 2007 15:13:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRy6-0000pC-2O for ram@iab.org; Mon, 02 Apr 2007 15:13:30 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRy4-0002ur-Gr for ram@iab.org; Mon, 02 Apr 2007 15:13:30 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l32Ixa61034832; Mon, 2 Apr 2007 11:59:40 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 12:13:17 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 12:13:17 -0700 In-Reply-To: <46114E69.20901@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <46114E69.20901@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> From: David Conrad Subject: Re: Scaling target (was: [RAM] Incremental Deployment of LISP) Date: Mon, 2 Apr 2007 12:13:11 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 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 Eliot, > And the whole point of the exercise is to engineer something the > provisioned mapping is relatively static Perhaps this is part of the disconnect. I am not making the assumption that the mapping is relatively static (however, I suspect this gets into the definition of 'relatively static'). > while the routing table remains stable or improves on the > performance curve over time. I am assuming this (otherwise, as you say, what's the point?). > You seem to think that this mapping will be huge. I don't know. I > guess that it will scale with the number of multihomed end points. No. My assumptions is that the mapping table will be approximately equal to the number of network attachment edge points. That is, the end state is that you have a locator numbered core interconnecting an identifier numbered edge. The mapping service translates the non- aggregatable identifier universe into the highly aggregateable locator universe. > I imagine that each entry in this table saves some space somewhere > in the RIB. I further envision that either big multihomed > enterprise h/w or PE h/w will perform the mapping. Simplifying a bit, I am assuming at every service provider/customer boundary (for some value of the variable "service provider"), there is a mapping device (what Dino calls an ITR) and that each one of those ITRs will require at least one mapping entry (more if they are multi-homed, which I expect to become the norm as opposed to the exception as more and more services depend on reliable IP service). The goal of the mapping is to ensure the RIB/FIB scales with the number of service providers, not the number of network attachment edge points. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 15:14:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRyB-0000rW-BY; Mon, 02 Apr 2007 15:13:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYRy9-0000r0-KH for ram@iab.org; Mon, 02 Apr 2007 15:13:33 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYRy8-0002uz-CA for ram@iab.org; Mon, 02 Apr 2007 15:13:33 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 12:13:27 -0700 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 l32JDR2F009468 for ; Mon, 2 Apr 2007 12:13:27 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32JDRA8028305 for ; Mon, 2 Apr 2007 19:13:27 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <05C82078-1381-439E-A5D2-FED25FE40838@virtualized.org> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <461148F8.4050804@cisco.com> <283DFE02-6396-43B9-92B3-E6C6DEF1ADEC@virtualized.org> <8DAC789F-339D-4096-9640-A6FFF0A5DDF1@cisco.com> <05C82078-1381-439E-A5D2-FED25FE40838@virtualized.org> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <33BCE8A5-2459-4CB6-AD89-0FF41970DC28@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 12:13:48 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=568; t=1175541207; x=1176405207; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=r1kJ5rXdMY32IJXliSvc+OimmD31v8yzWcasY1RPrvY=; b=RS0Q/sLh9Qo7anFJy/2aBQ90oQJHZC0ZrwOKCoaMz7gECJnCS/SCx1rWJr78ZaLTc5moRsbE 9CodTz+yLZF3wWdJbysVwIdl57t6UuA29aKWwzPELOsSW6zQ3Ah9G4Xo; 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: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 2, 2007, at 11:57 AM, David Conrad wrote: > high levels of dynamic behavior could be supported -- _much_ higher > than would be reasonably possible in a push based model. This is actually the first intrinsically desirable property which has been identified out of this whole subtopic, IMHO. Very interesting. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 15:30:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSD9-0005C3-Sn; Mon, 02 Apr 2007 15:29:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSD8-0005Bu-VR for ram@iab.org; Mon, 02 Apr 2007 15:29:02 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSD7-0005DC-IT for ram@iab.org; Mon, 02 Apr 2007 15:29:02 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 12:28:59 -0700 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 l32JSxaY004205; Mon, 2 Apr 2007 12:28:59 -0700 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 l32JSxA8003718; Mon, 2 Apr 2007 19:28:59 GMT 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, 2 Apr 2007 12:28:58 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 12:28:58 -0700 In-Reply-To: <4611232A.2030006@zurich.ibm.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@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: Tony Li Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 12:28:55 -0700 To: Brian E Carpenter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 19:28:58.0484 (UTC) FILETIME=[29129340:01C7755D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=526; t=1175542139; x=1176406139; c=relaxed/simple; s=sjdkim5002; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP] |Sender:=20; bh=q65O9LXoV08+CaRTfbHgQPkpfZHVih602X9P3M9tEus=; b=hYtEKLkdWlXTnJHzjrHTV3B45X25HhnK8/ud92FJuOR8jCJKIV25MZFELx7po5BjnDjWscm6 bVfsFGTPIFtD77f33OWoUmXb0FI1VnVSEdmCgPE/CatDZX9HqRxSlk5L; Authentication-Results: sj-dkim-5; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Fleischman, Eric" , 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 Apr 2, 2007, at 8:37 AM, Brian E Carpenter wrote: > But I think we need to design the locator mapping service to deal > with the worst case; if that is really 10M entries I am not too > frightened. It isn't the same problem as 10M DFZ routes. It can be made to be close. ;-) If we settle on a push model for mapping, and allow encapsulations to happen at arbitrary points in the network, then this looks a great deal like a core FIB. I'd prefer that we change either of the preconditions. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 15:53:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSZ6-000350-MZ; Mon, 02 Apr 2007 15:51:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSZ5-0002zy-6L for ram@iab.org; Mon, 02 Apr 2007 15:51:43 -0400 Received: from mux2.uit.no ([129.242.5.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSYy-0000To-Pb for ram@iab.org; Mon, 02 Apr 2007 15:51:43 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux2.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l32JpVec072287 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 21:51:31 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.12.10) with ESMTP id l32JpUG9028541; Mon, 2 Apr 2007 21:51:30 +0200 Date: Mon, 2 Apr 2007 21:51:29 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: "Fleischman, Eric" Subject: RE: [RAM] LISP and the Global Internet Architecture In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> Message-ID: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-226418608-1105806933-1175543489=:1566" X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.5.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---226418608-1105806933-1175543489=:1566 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mux2.uit.no id l32JpVec072287 On Mon, 2 Apr 2007, Fleischman, Eric wrote: > From: Roger Jorgensen [mailto:rogerj@jorgensen.no] >> What has to be changed with IPv6 to avoid it being self-defeating? > The architecture must not require widespread end user deployment in > order to work, as it currently does -- either that, or there must be a > truly compelling reason from the end user perspective for the end user > to want to support IPv6. > > IPv6 was originally designed to solve ISP problems to which the end use= r > has no visibility. > > IPv6 represents an expense for the end user but does not offer any > functionality to justify that expense -- there is no killer app for > IPv6. Until a killer app emerges, the end user is naturally motivated t= o > avoid introducing non-value-added variability to their infrastructure > and thereby significantly increase their own operations and support > costs. > > Worse yet, until IPv6 permitted PI addresses, it represented a mechanis= m > that required large end users to be held captive to their ISPs. This is > untenable to any end user and violates a fundamental law of economics > that businesses support the needs of their customers. Rather, the model > originally used by IPv6 was that customers support the needs of their > vendors. Not!!! In short, IPv6 are just more IP addresses, nothing else. Now we=B4re all=20 trying to solve the rest of the issues Internet have/will get. I=B4m just new to this side of the IPv6 discussion and are now trying to=20 figure out what the issue is people are trying to solve. Think I become a= =20 bit wiser now. --=20 ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- ---226418608-1105806933-1175543489=:1566 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 ---226418608-1105806933-1175543489=:1566-- From ram-bounces@iab.org Mon Apr 02 16:09:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSq7-0008EU-KR; Mon, 02 Apr 2007 16:09:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSq6-0008EH-9J for ram@iab.org; Mon, 02 Apr 2007 16:09:18 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSq4-0004Sq-OR for ram@iab.org; Mon, 02 Apr 2007 16:09:18 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l32K9F0s029686 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Apr 2007 13:09:16 -0700 Received: from [129.46.226.191] (carbuncle.qualcomm.com [129.46.226.191]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l32K9E9X019643 for ; Mon, 2 Apr 2007 13:09:15 -0700 (PDT) Mime-Version: 1.0 Message-Id: Date: Mon, 2 Apr 2007 13:09:13 -0700 To: ram@iab.org From: Ted Hardie Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Subject: [RAM] Application use of locators 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 several occasions, folks have asked for specifics of application use of locators in referrals. It might be useful for those wanting to see one edge of this to review: http://www.ietf.org/internet-drafts/draft-ietf-mmusic-ice-15.txt . It's a long spec, but it includes a good bit that is worth thinking through; in particular, it has replied to the IAB's Unilateral Self-Address Fixing (unsaf) document in some detail. It does not go fully into why it uses locators, saying: Protocols using offer/answer are difficult to operate through Network Address Translators (NAT). Because their purpose is to establish a flow of media packets, they tend to carry the IP of media sources and sinks within their messages, which is known to be problematic through NAT [16]. The protocols also seek to create a media flow directly between participants, so that there is no application layer intermediary between them. This is done to reduce media latency, decrease packet loss, and reduce the operational costs of deploying the application. However, this is difficult to accomplish through NAT. A full treatment of the reasons for this is beyond the scope of this specification. Despite this limitation, there is a lot here to show the extent to which an application will go to attempt to discover its place in the topologies of which it is part, in order to make its own routing decisions. I say routing here because I believe the application's choice of outbound interface is being treated like a next-hop decision in this context. Reading through the draft, it is moderately obvious that this is not how David Conrad would have done this (Your WWDRCDO? bracelet available now at Cafe Press). In a world in which the DNS protocol could be used to its fullest, the two end nodes which wished to use an offer-answer mechanism could do so either using some weight-contain record (an S-NAPTR record, say), a series of related records, or even fast-moving updates to a single DNS record like an A or AAAA per side. Even if all of those approaches are stupid, it is likely that some id/locator split based on the DNS is possible in this case. So, why wasn't that the approach taken here? I have two speculations, which may have implications for further thought here. Speculation one: split DNS generally hasn't been done well. Split DNS means that the data you get out of the DNS is different depending on where in the network topology you are when you ask the question. Updating records in the presence of split DNS presents a policy problem, as it is difficult to determine which side(s) of the split DNS should get the updates. While it would theoretically be possible for a node at RFC 1918 address 10.0.2.3 to update its A record to its STUN-determined external address of 66.160.187.27, this just doesn't seem to work in a lot of the DNS deployments out there today. That means that an end node trying to use the DNS to communicate how it is reachable may not be able to do so effectively, especially since the seams in the split DNS are not exposed to the end node for discovery. Speculation two: even if speculation one's problem were corrected, the connectivity check problem would remain. As the draft puts it: The second property is important for getting ICE to work when there are NATs in front of L and R. Frequently, NATs will not allow packets in from a host until the agent behind the NAT has sent a packet towards that host. Consequently, ICE checks in each direction will not succeed until both sides have sent a check through their respective NATs. This policy institution is aimed to avoid stupid bad guys from port-scanning weak hosts. If NATs were done away with, I strongly suspect that this functionality would be shifted to firewalls (many of which also have this characteristic). The connectivity check problem means that even if I somehow succeed in telling you an external address at which I should be reachable, I need to enable that address's validity *for flows from some other specific point in the topology*, or the network will not route the packets. That's not lovely, but it is likely reality. I have some potential conclusions from those speculations, but I'd like to hear others' thoughts on the ICE architecture before I make a fool of myself (after all, I might have some much larger way of doing so with the extra help). regards, Ted Hardie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 16:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw4-0000z3-Na; Mon, 02 Apr 2007 16:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw3-0000yd-9b for ram@iab.org; Mon, 02 Apr 2007 16:15:27 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSw1-0005c5-QH for ram@iab.org; Mon, 02 Apr 2007 16:15:27 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l32KFKfk046780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 22:15:20 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.12.10) with ESMTP id l32KFJcE029980; Mon, 2 Apr 2007 22:15:20 +0200 Date: Mon, 2 Apr 2007 22:15:19 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture In-Reply-To: Message-ID: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-226418608-1458046043-1175544919=:1566" X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Fleischman, Eric" , 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---226418608-1458046043-1175544919=:1566 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mux1.uit.no id l32KFKfk046780 On Mon, 2 Apr 2007, David Conrad wrote: > To clarify, I'd argue that the vast majority of end users couldn't care= less=20 > whether they had IPv4, IPv6, NSAPs, or lima beans for addresses. What = end=20 > users care about is continued accessibility to network services of vari= ous=20 > flavors and kinds. Until this can be provided over IPv6, with no need = for=20 > any significant end user (or end user supporting organization) configur= ation=20 > changes, IPv6 will remain dead in the water. That=B4s all so true. I work for an organization/company owned=20 indirect by the state and our only goal is to provide electronic=20 infrastructure so there can be widespread use of what the world know as=20 Telemedicine. We have so much trouble with IPv4 due to every possible=20 reason and how they would react to IPv6...no idea. Bottom line, our end-users, doctors working with patients everyday only=20 care about one singel thing, to be able to communicate with the hospitals= =20 and other they need in their daily work. IPv6 are faaaar from ready for those users even tho most of our problems=20 with be solved with IPv6. Problems like NAT, double NAT and tripple NAT,=20 conflicting IP addresses due to every hospital/county have their own=20 network using RFC1918 addresses... --=20 ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- ---226418608-1458046043-1175544919=:1566 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 ---226418608-1458046043-1175544919=:1566-- From ram-bounces@iab.org Mon Apr 02 16:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw7-00010z-4L; Mon, 02 Apr 2007 16:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw5-000109-H4 for ram@iab.org; Mon, 02 Apr 2007 16:15:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSw3-0005cg-6Y for ram@iab.org; Mon, 02 Apr 2007 16:15:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 13:15:28 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32KFQHE028752 for ; Mon, 2 Apr 2007 13:15:26 -0700 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 l32KFQMH011604 for ; Mon, 2 Apr 2007 20:15:26 GMT 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, 2 Apr 2007 13:15:26 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:15:26 -0700 In-Reply-To: <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.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: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 13:15:24 -0700 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 20:15:26.0185 (UTC) FILETIME=[A6ABFD90:01C77563] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=604; t=1175544926; x=1176408926; c=relaxed/simple; s=sjdkim1004; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=rzkIjzU7aPb17awpVNF8XnzuWfFFg4XVjMw3MUkMImQ=; b=W2TSA18zQ1Xy9/AAPV2xhXgSFXT2LCRbGY+tjax/9RlXkqM5kO2e2KhtC7efeIx6mAXIUQmS xjk+rgI0xWhd7JmEyu6OgfGy9J0qhmYEF1kHo2sjnxCivUEsdQJjjFU9mQq7K7ni0/bWKksecz 6b+4Deac2nFuINxXVexeAN6rc=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 PreFrom ram-bounces@iab.org Mon Apr 02 16:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw4-0000z3-Na; Mon, 02 Apr 2007 16:15:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw3-0000yd-9b for ram@iab.org; Mon, 02 Apr 2007 16:15:27 -0400 Received: from mux1.uit.no ([129.242.4.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSw1-0005c5-QH for ram@iab.org; Mon, 02 Apr 2007 16:15:27 -0400 Received: from shimmer.student.uit.no (shimmer.student.uit.no [129.242.80.34]) by mux1.uit.no (8.13.8/8.13.6/Mux) with ESMTP id l32KFKfk046780 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 2 Apr 2007 22:15:20 +0200 (CEST) Received: from chandra.student.uit.no (chandra.student.uit.no [129.242.80.32]) by shimmer.student.uit.no (8.13.1/8.12.10) with ESMTP id l32KFJcE029980; Mon, 2 Apr 2007 22:15:20 +0200 Date: Mon, 2 Apr 2007 22:15:19 +0200 (CEST) From: Roger Jorgensen X-X-Sender: rogerj@chandra.student.uit.no To: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture In-Reply-To: Message-ID: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="-226418608-1458046043-1175544919=:1566" X-Virus-Scanned: : ok X-Scanned-By: MIMEDefang 2.61 on 129.242.4.252 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: "Fleischman, Eric" , 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 message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. ---226418608-1458046043-1175544919=:1566 Content-Type: TEXT/PLAIN; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by mux1.uit.no id l32KFKfk046780 On Mon, 2 Apr 2007, David Conrad wrote: > To clarify, I'd argue that the vast majority of end users couldn't care= less=20 > whether they had IPv4, IPv6, NSAPs, or lima beans for addresses. What = end=20 > users care about is continued accessibility to network services of vari= ous=20 > flavors and kinds. Until this can be provided over IPv6, with no need = for=20 > any significant end user (or end user supporting organization) configur= ation=20 > changes, IPv6 will remain dead in the water. That=B4s all so true. I work for an organization/company owned=20 indirect by the state and our only goal is to provide electronic=20 infrastructure so there can be widespread use of what the world know as=20 Telemedicine. We have so much trouble with IPv4 due to every possible=20 reason and how they would react to IPv6...no idea. Bottom line, our end-users, doctors working with patients everyday only=20 care about onecedence: 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 Apr 2, 2007, at 10:50 AM, Roland Dobbins wrote: >> Assuming a pull model, there's no real reason that a router can't >> implement a cache of mappings, even if the lookup is off-box. If >> you trigger the mapping based on a DNS request, as Fred has >> suggested, then the cache can be pre-populated before the first >> data packet arrives. > > What about IP communications which don't involve DNS lookups? A > fair amount of VoIP is done this way, for example. I suspect that you can guess how I feel about applications that choose to do referrals by IP address. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram singel thing, to be able to communicate with the hospitals= =20 and other they need in their daily work. IPv6 are faaaar from ready for those users even tho most of our problems=20 with be solved with IPv6. Problems like NAT, double NAT and tripple NAT,=20 conflicting IP addresses due to every hospital/county have their own=20 network using RFC1918 addresses... --=20 ------------------------------ Roger Jorgensen | - ROJO9-RIPE - RJ85P-NORID roger@jorgensen.no | - IPv6 is The Key! ------------------------------------------------------- ---226418608-1458046043-1175544919=:1566 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 ---226418608-1458046043-1175544919=:1566-- From ram-bounces@iab.org Mon Apr 02 16:16:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw7-00010z-4L; Mon, 02 Apr 2007 16:15:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYSw5-000109-H4 for ram@iab.org; Mon, 02 Apr 2007 16:15:29 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYSw3-0005cg-6Y for ram@iab.org; Mon, 02 Apr 2007 16:15:29 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 13:15:28 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l32KFQHE028752 for ; Mon, 2 Apr 2007 13:15:26 -0700 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 l32KFQMH011604 for ; Mon, 2 Apr 2007 20:15:26 GMT 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, 2 Apr 2007 13:15:26 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:15:26 -0700 In-Reply-To: <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.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: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 13:15:24 -0700 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 20:15:26.0185 (UTC) FILETIME=[A6ABFD90:01C77563] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=604; t=1175544926; x=1176408926; c=relaxed/simple; s=sjdkim1004; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=rzkIjzU7aPb17awpVNF8XnzuWfFFg4XVjMw3MUkMImQ=; b=W2TSA18zQ1Xy9/AAPV2xhXgSFXT2LCRbGY+tjax/9RlXkqM5kO2e2KhtC7efeIx6mAXIUQmS xjk+rgI0xWhd7JmEyu6OgfGy9J0qhmYEF1kHo2sjnxCivUEsdQJjjFU9mQq7K7ni0/bWKksecz 6b+4Deac2nFuINxXVexeAN6rc=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Apr 2, 2007, at 10:50 AM, Roland Dobbins wrote: >> Assuming a pull model, there's no real reason that a router can't >> implement a cache of mappings, even if the lookup is off-box. If >> you trigger the mapping based on a DNS request, as Fred has >> suggested, then the cache can be pre-populated before the first >> data packet arrives. > > What about IP communications which don't involve DNS lookups? A > fair amount of VoIP is done this way, for example. I suspect that you can guess how I feel about applications that choose to do referrals by IP address. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 16:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT16-0001w6-ME; Mon, 02 Apr 2007 16:20:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT15-0001vr-8v for ram@iab.org; Mon, 02 Apr 2007 16:20:39 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT13-0006zr-02 for ram@iab.org; Mon, 02 Apr 2007 16:20:38 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 13:20:36 -0700 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 l32KKa8D006537; Mon, 2 Apr 2007 13:20:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l32KKaEi000473; Mon, 2 Apr 2007 20:20:36 GMT 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, 2 Apr 2007 13:20:36 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:20:35 -0700 In-Reply-To: <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 13:20:33 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 20:20:35.0516 (UTC) FILETIME=[5F0C27C0:01C77564] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=643; t=1175545236; x=1176409236; c=relaxed/simple; s=sjdkim2002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=ztIUSEMzAI+B/BV1pSHoy36FT0BwNktKua0ELzZDN4E=; b=E4cxF26gmKoHYk3NkAx4SD0jREquIjF6nyPBUn8UHrTOxSwNm3oaKX18WUvjfNoOwcQHM+La bWzY62vKE5CLvhds2jKYnD0dKUI09tbH/q5OT7ztvqlZPJ2wPw2cAcYu; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: "Templin, Fred L" , 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 Apr 2, 2007, at 11:30 AM, David Conrad wrote: > I'd agree with "DNS server" and "ITR", however assuming the DNS > server has to be numbered out of locator space instead of > identifier space, putting the host on the same physical platform > means you lose one of the big advantages of ID/LOC separation: the > ability to transparently "renumber". That's only an issue if there are other hosts dependent on that "DNS server" functionality. If one was to co-locate everything, then you can effectively morph LISP into being a purely host-based solution. This has wonderful benefits for scalability. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 16:22:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT2i-0004CK-6m; Mon, 02 Apr 2007 16:22:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT2g-0004As-SQ for ram@iab.org; Mon, 02 Apr 2007 16:22:18 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT2f-0007Fh-KA for ram@iab.org; Mon, 02 Apr 2007 16:22:18 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 13:22:16 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l32KMGXo012554 for ; Mon, 2 Apr 2007 13:22:16 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l32KMFA8027750 for ; Mon, 2 Apr 2007 20:22:16 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 13:22:37 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=568; t=1175545336; x=1176409336; c=relaxed/simple; s=sjdkim6002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=/BwAkF4sOPvL3adL/XjWUKQw+LlHvmfUw+WTGm3PCmk=; b=IYSmt9aW2aHeYnwJKWGQ6+VKzfmj/QVLBW6x7UpZeS3S55bLSFGLlctDI1Qds/q/0et7U518 InVW7Ig9I68OAeEe+WKH/cfkFGuI/XpJxHu//5yD8p57UpruDd3U2v0o; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 Apr 2, 2007, at 1:15 PM, Tony Li wrote: > I suspect that you can guess how I feel about applications that > choose to do referrals by IP address. I largely share those sentiments, but that doesn't negate the fact that a) they exist, b) people like/use them, and c) therefore they must be taken into account, heh. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 16:26:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT6d-0000R0-7E; Mon, 02 Apr 2007 16:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT6c-0000Qq-El for ram@iab.org; Mon, 02 Apr 2007 16:26:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT6b-0008Hx-5J for ram@iab.org; Mon, 02 Apr 2007 16:26:22 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 13:26:20 -0700 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 l32KQKu1011911 for ; Mon, 2 Apr 2007 13:26:20 -0700 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 l32KQ1ZV006337 for ; Mon, 2 Apr 2007 20:26:20 GMT 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, 2 Apr 2007 13:26:17 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 13:26:17 -0700 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <09FCBD08-6613-49D8-90C9-4B3AF4FA23EA@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 13:26:15 -0700 To: Roland Dobbins X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 02 Apr 2007 20:26:17.0062 (UTC) FILETIME=[2A9FF060:01C77565] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=350; t=1175545580; x=1176409580; c=relaxed/simple; s=sjdkim1004; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=qVRWuMLFbVFlC+hxC/KJIafGXZ8zyrcDdE1bCUJ7bj0=; b=LZPnuHK5c9W0wkqy2IX1VBCf2wZtOfYrNNboUshmy2OttwFMQpMQxWy+8H71vHPCYmI8U3oB iNntHVKslalTzQakmWDGPDKwh2Z/ulXZ13imCL3sgH0vZPnNgZueZIxYEVcD9HBCrwoNBBPhWE hKoZoneMH5KtcRACWt5jPPDf0=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 Apr 2, 2007, at 1:22 PM, Roland Dobbins wrote: > I largely share those sentiments, but that doesn't negate the fact > that a) they exist, b) people like/use them, and c) therefore they > must be taken into account, heh. Then you'll have no issues with the fact that there may be a mapping delay for those applications. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 16:26:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT75-0000cU-LR; Mon, 02 Apr 2007 16:26:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYT73-0000cM-W6 for ram@iab.org; Mon, 02 Apr 2007 16:26:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYT6z-0008LM-Si for ram@iab.org; Mon, 02 Apr 2007 16:26:49 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l32KQeUa015666 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 2 Apr 2007 13:26:41 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l32KQe83020169; Mon, 2 Apr 2007 15:26:40 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l32KQRxk019908; Mon, 2 Apr 2007 15:26:40 -0500 (CDT) 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); Mon, 2 Apr 2007 13:26:36 -0700 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] Application use of locators Date: Mon, 2 Apr 2007 13:26:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774878@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Application use of locators Thread-Index: Acd1YunnCwTqSJNhRBmvyRC+Bb1qCgAAWADw References: From: "Templin, Fred L" To: "Ted Hardie" , X-OriginalArrivalTime: 02 Apr 2007 20:26:36.0206 (UTC) FILETIME=[360914E0:01C77565] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 Ted, Replying to just one aspect of your interesting post:=20 > in particular, it has replied to the IAB's Unilateral > Self-Address Fixing (unsaf) document in some detail. Here is what (RFC4380, Section 8.4) has to say about UNSAF, which more or less matches the IPvLX paradigm: "Our experience with Teredo has led to the following requirements for a long-term solution to the NAT problem: the devices that implement the IPv4 NAT services should in the future also become IPv6 routers." Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 16:35:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTET-0003nm-I2; Mon, 02 Apr 2007 16:34:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTES-0003ng-9H for ram@iab.org; Mon, 02 Apr 2007 16:34:28 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYTEQ-0001OU-0Q for ram@iab.org; Mon, 02 Apr 2007 16:34:28 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 13:34:25 -0700 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 l32KYPNP004101 for ; Mon, 2 Apr 2007 13:34:25 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l32KYPwn007290 for ; Mon, 2 Apr 2007 20:34:25 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <09FCBD08-6613-49D8-90C9-4B3AF4FA23EA@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com> <09FCBD08-6613-49D8-90C9-4B3AF4FA23EA@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <4BE05A64-C9A1-458F-A162-F839E192B0A3@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 13:34:46 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=953; t=1175546065; x=1176410065; c=relaxed/simple; s=sjdkim5002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=SJ3N4mk7eTPdDFzOXbvPY7V61cNxI9UcyA86BNsGoy4=; b=hpumfS6mb2DnWwm3uPcVbLO0H8Hlm3XhgAqNRPaJI8C9/VLnBTOI1gVKpV7YIFhssW6u1MzS uTyIdAcVn4HLMSC02tDuJze0EuYI2P1cxgCxVo5jYua2IDwzu95muY7u; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Apr 2, 2007, at 1:26 PM, Tony Li wrote: > Then you'll have no issues with the fact that there may be a > mapping delay for those applications. I won't, but the users may well, depending upon the length of the delay and its effect on the applications - we can't just arbitrarily impose a delay without some stab at quantifying it and gaining an understanding of its potential impact to things which users rely upon, IMHO. I'm concerned that there may be some fairly negative impact to some VoIP systems, other things like SCADA and/or HVAC systems (which oughtn't to be running across the Internet, anyways, but that's a different discussion), medical imaging systems (same), etc. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 17:05: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 1HYTgk-0005Wq-26; Mon, 02 Apr 2007 17:03:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYTgj-0005Wk-38 for ram@iab.org; Mon, 02 Apr 2007 17:03:41 -0400 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 1HYTgh-0008Mk-SN for ram@iab.org; Mon, 02 Apr 2007 17:03:41 -0400 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 l32L3clw003017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 2 Apr 2007 16:03:39 -0500 (CDT) 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 l32L3csc012705 for ; Mon, 2 Apr 2007 14:03:38 -0700 (PDT) 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 l32L3aHQ012631 for ; Mon, 2 Apr 2007 14:03:38 -0700 (PDT) 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); Mon, 2 Apr 2007 14:03:35 -0700 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: Mon, 2 Apr 2007 14:03:34 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774879@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4BE05A64-C9A1-458F-A162-F839E192B0A3@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: locator/identifier assumptions Thread-Index: Acd1ZmKNXIZx0DfCQruHA3d8JtCH2AAAuzRg References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com><09FCBD08-6613-49D8-90C9-4B3AF4FA23EA@cisco.com> <4BE05A64-C9A1-458F-A162-F839E192B0A3@cisco.com> From: "Templin, Fred L" To: X-OriginalArrivalTime: 02 Apr 2007 21:03:35.0157 (UTC) FILETIME=[60A22250:01C7756A] X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [RAM] locator/identifier assumptions 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 have been operating under the following assumptions: 1) LISP 1 - locators and identifers are globally routable IPv4 addresses. 2) LISP 1.5 - locators are globally routable IPv4 addresses, and identifiers are IPv6 addresses that are routeable on a global IPv6 infrastructure, e.g., the 6Bone. 3) LISP 2/3 - locators are globally routable IPv4 addresses, and identifiers are IPv6 addresses that are routeable only within the local enterprise/site. IPv6 ULAs (RFC4193) provide a natural addressing mechanism for this. Comments? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 17:53:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYURY-0006Tr-Pn; Mon, 02 Apr 2007 17:52:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYURX-0006Tl-30 for ram@iab.org; Mon, 02 Apr 2007 17:52:03 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYURV-0000SC-SA for ram@iab.org; Mon, 02 Apr 2007 17:52:03 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 02 Apr 2007 14:52:02 -0700 X-IronPort-AV: i="4.14,362,1170662400"; d="scan'208"; a="701270557:sNHT32298744" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l32Lq1J08204; Mon, 2 Apr 2007 14:52:01 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704022152.l32Lq1J08204@merlot.juniper.net> To: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: Your message of "Sun, 01 Apr 2007 23:36:55 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <31905.1175550721.1@juniper.net> Date: Mon, 02 Apr 2007 14:52:01 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 think LISP 1.5+ is about as deployable as NIMROD+MPLS :-> (and > > less so > > than IPv6) > > We could deploy LISP today on the MBGP topology. That would be an > example of LISP 1.5, that is AFI=ipv4,SAFI=multicast. This would be an good example to illustrate that LISP 1.5 offer *no* reduction of the volume of routing information. To the contrary, this example would illustrate how LISP 1.5 would result in increasing volume of routing information. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 19:08:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVbv-0000Of-7a; Mon, 02 Apr 2007 19:06:51 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYVbt-0000OY-67 for ram@iab.org; Mon, 02 Apr 2007 19:06:49 -0400 Received: from imo-m26.mx.aol.com ([64.12.137.7]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYVbS-0001g4-R3 for ram@iab.org; Mon, 02 Apr 2007 19:06:49 -0400 Received: from HeinerHummel@aol.com by imo-m26.mx.aol.com (mail_out_v38_r8.1.) id 1.cb7.cc7f405 (29678); Mon, 2 Apr 2007 19:06:15 -0400 (EDT) From: HeinerHummel@aol.com Message-ID: Date: Mon, 2 Apr 2007 19:06:15 EDT Subject: Re: [RAM] Incremental Deployment of LISP To: yakov@juniper.net, dino@cisco.com MIME-Version: 1.0 X-Mailer: 9.0 SE for Windows sub 5009 X-Spam-Flag: NO X-Spam-Score: 0.3 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 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="===============1833689455==" Errors-To: ram-bounces@iab.org --===============1833689455== Content-Type: multipart/alternative; boundary="-----------------------------1175555175" -------------------------------1175555175 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable =20 Well spoken, Yakov. Being the BGP expert per se, I can imagine that you =20 would favor only such a BGP-substitute which really reduces the world-wide=20= =20 UPDATE churn, especially those updates which do not change the next-hop dec= ision=20 at all, right ? Heiner =20 In einer eMail vom 02.04.2007 23:53:22 Westeurop=E4ische Normalzeit schreibt= =20 yakov@juniper.net: Dino, > > I think LISP 1.5+ is about as deployable as NIMROD+MPLS :-> (and =20 > > less so > > than IPv6) >=20 > We could deploy LISP today on the MBGP topology. That would be an =20 > example of LISP 1.5, that is AFI=3Dipv4,SAFI=3Dmulticast. This would be an good example to illustrate that LISP 1.5 offer *no* reduction of the volume of routing information. To the contrary, this example would illustrate how LISP 1.5 would result in increasing volume of routing information.=20 Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram =20 -------------------------------1175555175 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Well spoken, Yakov. Being the BGP expert per se, I can imagine that you= =20 would favor  only such a BGP-substitute which really reduces the world-= wide=20 UPDATE churn, especially those updates which do not change the next-hop= =20 decision at all, right ?
Heiner
 
In einer eMail vom 02.04.2007 23:53:22 Westeurop=E4ische Normalzeit sch= reibt=20 yakov@juniper.net:
<= FONT=20 style=3D"BACKGROUND-COLOR: transparent" face=3DArial color=3D#000000=20 size=3D2>Dino,

> > I think LISP 1.5+ is about as deployable a= s=20 NIMROD+MPLS :-> (and 
> > less so
> > than=20 IPv6)
>
> We could deploy LISP today on the MBGP topology. Th= at=20 would be an 
> example of LISP 1.5, that is=20 AFI=3Dipv4,SAFI=3Dmulticast.

This would be an good example to illus= trate=20 that LISP 1.5 offer
*no* reduction of the volume of routing=20 information.  To the contrary,
this example would illustrate how L= ISP=20 1.5 would result in increasing
volume of routing information.
 = ;=20
Yakov.

_______________________________________________
RAM=20 mailing=20 list
RAM@iab.org
https://www1.ietf.org/mailman/listinfo/ram
 
 -------------------------------1175555175-- --===============1833689455== 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 --===============1833689455==-- From ram-bounces@iab.org Mon Apr 02 20:00:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWPi-0002L5-8G; Mon, 02 Apr 2007 19:58:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWPh-0002Hq-Fd for ram@iab.org; Mon, 02 Apr 2007 19:58:17 -0400 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYWPg-0003Ru-Gd for ram@iab.org; Mon, 02 Apr 2007 19:58:17 -0400 Received: from [134.129.105.135] (dyn135.wireless-105.ndsu.NoDak.edu [134.129.105.135]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l32Nw9Ut007983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 2 Apr 2007 18:58:09 -0500 Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774871@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774871@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 18:57:17 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-Spam-Score: -2.7 (--) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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 Apr 2, 2007, at 12:19 PM, Templin, Fred L wrote: > David/Eliot, > > This goes back to what I said in an earlier message: > > + You seem to be assuming that the mapping will be driven by > + the first packet out the door; I'm not assuming that at all. > + For inter-site communications, there will always be an initial > + FQDN-to-locator resolution before a session starts, and the > + mapping can be done then before any packets are sent. > > So, I really don't see a reason to be worried about new delay > models at all. > > Fred > fred.l.templin@boeing.com If sites follow RFC 2182 then they will have at least one secondary DNS server that won't have the same mapping as the primary DNS server. So the FQDN-to-locator resolution may not always have the same mapping as the packets to the destination site that follow. For customers of at least one company, Akamai, the FQDN-to-locator resolution mapping will likely always be different than the mapping for the destination site. > > >> -----Original Message----- >> From: David Conrad [mailto:drc@virtualized.org] >> Sent: Monday, April 02, 2007 10:14 AM >> To: Eliot Lear >> Cc: ram@iab.org >> Subject: Re: [RAM] Incremental Deployment of LISP >> >> Eliot, >> >> On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: >>>> [latency] >>> Because we shouldn't engineer delay into the system, >> >> There are already numerous delays engineered into the system. >> >>> and second, because that is what matches existing behavior today. >> >> How long does it take for a router that takes full routes when it >> initially started to be able to forward packets? A system >> based on a >> pull model would be able to avoid this delay. >> >>> Want to take a guess as to which applications need that 1ms and >>> which don't? >> >> Why 1ms? Why not 10ms or 0.1ms? None of these numbers appear to be >> backed up by any empirical evidence. >> >>> I sure as heck don't want to be there. >> >> Name one application that can't tolerate a delay on initial start >> up. Realistically, since we're talking about a datagram based >> network with best effort delivery, the additional latency that would >> exist in an on-demand pull-based model would be lost in the noise of >> initial communication establishment. >> >>>> [buffering] >>> First because that's not what routers should be for. Routers are >>> for *delivering* packets not *storing* them. >> >> Good thing we don't need ARP. >> >> Routers already buffer. >> >>> Moreover, it's not just one packet- it's going to be a train of >>> packets, more likely. >> >> Last I checked, TCP-based traffic outweighed all other traffic >> significantly. >> >>> People keep talking as if we're talking about a single packet, >>> presuming that in each case a conversation is beginning. That may >>> be a false assumption. >> >> Yes, there can be cases where the first packet in a transaction is >> actually a set of packets, in which case, the router has the choice >> of buffering or dropping until the mapping can be performed. >> >> In an ideal world, I would agree that it would be really nice >> to have >> the entire mapping table local. However, I believe this >> simply won't >> scale. You're moving the routing table thrash problem from a >> smallish set of really well connected core routers down to >> every edge >> system (for some value of the variable "edge"). You can >> "solve" this >> problem somewhat by artificially constraining how frequently the >> table changes, but you're the one who is saying we shouldn't >> engineer >> delays into the system. >> >> Rgds, >> -drc >> >> >> _______________________________________________ >> 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 > --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:08:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWYj-0002eX-M0; Mon, 02 Apr 2007 20:07:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWYi-0002eS-LS for ram@iab.org; Mon, 02 Apr 2007 20:07:36 -0400 Received: from xmail06.myhosting.com ([168.144.250.220]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYWYh-0006Gi-Ax for ram@iab.org; Mon, 02 Apr 2007 20:07:36 -0400 Received: (qmail 31198 invoked from network); 3 Apr 2007 00:07:24 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail06.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 00:07:23 -0000 Message-ID: <46119A6D.7070208@cisco.com> Date: Mon, 02 Apr 2007 20:06:05 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [RAM] MANETs and LISP References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 >> From: Roland Dobbins [mailto:rdobbins@cisco.com] >> Does a LISP-like solution lend itself to MANET? > > Since I've been working with MANET for many years now, this is a point > that I have thought about quite a bit. In my personal opinion (i.e., I > don't expect you to agree), the historic IP protocol is inherently > designed for stable environments and becomes severely challenged by > MANET attributes (e.g., mobility, signal intermittence, transitory > relationships). The two (i.e., traditional IP and MANET) can (and do) > coexist, but their interface point(s) needs to satisfy the requirements > of both communities. > > It is my personal opinion (i.e., I again don't expect you to agree) that > because BGP is particularly poorly suited for supporting MANETs (e.g., > pairwise relationships, no discovery), that a natural place to relate > MANETs with traditional IP is at the AS boundary, because to extend > MANETs beyond the AS boundary needs to overcome the vast problems that > BGP has in highly mobile, highly signal intermittence environments. One thing that disturbs me about this entire discussion is the provider centric view of the world. Yes, providers exist in a certain form today. They might not exist in that form, or any form, in the next ten years. If we design the Internet around current provider modes of operation, we'll have frozen a business model in place with no specific reason to have done so, other than that's the business model that existed when the music stopped. As for MANET, if you look at the MANET as some sort of cloud that connects to some provider, and LISP as a provider edge only solution, then your analysis is right. In fact, as long as you see MANET as a cloud attached to a provider, just about anything will work with MANET, since it really doesn't run with a MANET, but on the stable network the MANET actually attaches to. If you try to actually figure out how LISP of any type would work _in_ a MANET, rather than with a MANET attached to it, you'll face much larger challenges, though. As long as the network locators remain stable, we are being told LISP will reduce the churn in the network. I'm not at all convinced of this, but let's run with it a second, and see where it leads. Now, when the locators and the IDs are in constant flux, then the mapping system between the two has to deal with churn on both sides, not just one, and things don't line up so nicely. My guess is this would be worse than "normal" IP, but without spending some time on a whiteboard, it would be hard to know, for certain. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEZptER27sUhU9OQRAk60AKCG7iAksgsfH43G3Mo7ZDjw3MB7ywCgtvJn Q3oOCGQSJBv8nGsakFh5KiM= =gtCv -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:23:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWnN-00053t-TF; Mon, 02 Apr 2007 20:22:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWnN-00053n-7B for ram@iab.org; Mon, 02 Apr 2007 20:22:45 -0400 Received: from xmail10.myhosting.com ([168.144.250.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYWnL-0000Gx-Uj for ram@iab.org; Mon, 02 Apr 2007 20:22:45 -0400 Received: (qmail 19891 invoked from network); 3 Apr 2007 00:22:43 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 00:22:42 -0000 Message-ID: <46119E04.60107@cisco.com> Date: Mon, 02 Apr 2007 20:21:24 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Fleischman, Eric" Subject: Re: [RAM] LISP and the Global Internet Architecture References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 > Yes!!! I fully agree. LISP offers this promise. Whatever the IETF > finally chooses also needs to do this, if we are going to finally have a > realistic (non-mythical) architecture. What gain would an Enterprise be able to point to if they deployed LISP at their internal edge routers? 1. They made their internal routing tables smaller. They weren't big to begin with. 2. They reduced the churn in their routing tables, and, most likely, increased the churn in some other table. 3. They added more software and, quite possibly, boxes to support it. 4. They made their ISP's tables smaller. Big deal. If I'm an Enterprise customer, why am I buying this? I'm certainly cementing the current business model of the Internet in place, but I'm not certain that buys me much of anything, either, does it? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEZ4EER27sUhU9OQRAkpGAJ9b5TYzPkYaxf1OUmu4nyXwdFrikgCdFbTQ OLA70qIdE5Cu/KadWvw2aSQ= =Vxp/ -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:28:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWt9-0002uq-15; Mon, 02 Apr 2007 20:28:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWt7-0002uU-Rj for ram@iab.org; Mon, 02 Apr 2007 20:28:41 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYWt6-0002HG-Io for ram@iab.org; Mon, 02 Apr 2007 20:28:41 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 17:28:38 -0700 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 l330ScNt010150 for ; Mon, 2 Apr 2007 17:28:38 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l330SbA8028729 for ; Tue, 3 Apr 2007 00:28:37 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46119A6D.7070208@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> <46119A6D.7070208@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3CBE5939-F7C2-49C7-B732-AFF3C59BEF61@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] MANETs and LISP Date: Mon, 2 Apr 2007 17:28:59 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1405; t=1175560118; x=1176424118; 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]=20MANETs=20and=20LISP |Sender:=20; bh=GzTK6zgwSSugl53k2EiUKpwHt5n/kS3DvJxo1Zp6lnc=; b=nP2g1uQSrokPSs3W+Lfmhr3a4jY57KOunCC7bDrNNbYlmyzNeOq672DltD24BdYvQIIw2+mp 4DuHoXCB/kiQNgyASm9nIbgSrIWm9z8o2vRSrttcCmP2yx5/+BTOZt+9; 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: 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 On Apr 2, 2007, at 5:06 PM, Russ White wrote: > One thing that disturbs me about this entire discussion is the > provider > centric view of the world. Yes, providers exist in a certain form > today. > They might not exist in that form, or any form, in the next ten years. > If we design the Internet around current provider modes of operation, > we'll have frozen a business model in place with no specific reason to > have done so, other than that's the business model that existed > when the > music stopped. This is what I was trying to get at indirectly by asking about disintermedation and MANET. ;> The current NSP business model has been largely shaped by the conflation of host/locator, and with the notion of upstream/ downstream/peering as distinct modes of connectivity as an indirect result, IMHO. Given the impetus behind the LISP proposal in no small part is a reaction to various economic pressures, incentives for selfish behavior, etc. which surround that business model, it seems that spending some time thinking about whether what we're doing is 'futureproofed' in this regard might be worthwhile. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:32: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 1HYWwI-0005AB-8p; Mon, 02 Apr 2007 20:31:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYWwH-0004zk-3P for ram@iab.org; Mon, 02 Apr 2007 20:31:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYWwF-0003CD-RR for ram@iab.org; Mon, 02 Apr 2007 20:31:57 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 17:31:55 -0700 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 l330Vt00031960 for ; Mon, 2 Apr 2007 17:31:55 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l330VrA8029493 for ; Tue, 3 Apr 2007 00:31:55 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <46119E04.60107@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 17:32:14 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=778; t=1175560315; x=1176424315; c=relaxed/simple; s=sjdkim5002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=I3N7BTSpcf89dzQK4jZMrWZTmABmenP+yarK3EYD+0M=; b=xzwl4Vg8OWc8J5Ek37sVeRDP/dyvgFESuF7YNdisDalYwnayhmGElnKEJAeFjkaWsx3N84Yt ljArLjsNdCLXm41grmEL/nJKPiUawmcKg7t7Dnbd2SnWW9eXLyJDHTkR; Authentication-Results: sj-dkim-5; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 Apr 2, 2007, at 5:21 PM, Russ White wrote: > If I'm an Enterprise customer, why am I buying this? I'm certainly > cementing the current business model of the Internet in place, but I'm > not certain that buys me much of anything, either, does it? It may be that the primary advantage for some enterprises would be to say that they're Doing Something in terms of deploying/enabling IPv6, which they may be under various non-technical pressures to deploy, irrespective of need and/or direct applicability to a problem-set. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:48:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXBF-0007cJ-QN; Mon, 02 Apr 2007 20:47:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXBE-0007cE-UO for ram@iab.org; Mon, 02 Apr 2007 20:47:24 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXBD-00007Z-Gm for ram@iab.org; Mon, 02 Apr 2007 20:47:24 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l330Xc61035457; Mon, 2 Apr 2007 17:33:39 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 17:47:15 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 17:47:15 -0700 In-Reply-To: <46119E04.60107@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 17:47:13 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Russ, On Apr 2, 2007, at 5:21 PM, Russ White wrote: > What gain would an Enterprise be able to point to if they deployed > LISP > at their internal edge routers? - The ability to change service providers without affecting internal hosts. - Not having to convince/pay the enterprise's service provider(s) to route an additional PI prefix (the ISP-size of the edge would, of course, be provider aggregatable). The former benefit is, of course, gained by using PI (unless the RIRs reverse current trends and made PI (for use in routing, that is locators) more difficult to obtain). However, as the routing system bloats, I suspect the latter benefit will come more and more into play. Note that since end point identifiers do not need to be aggregatable for routing purposes, there is no reason they need to be allocated hierarchically. As such, alternative allocation models could be used. Not sure this is a benefit, but thought I'd mention it. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:48:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXCd-0000vE-HY; Mon, 02 Apr 2007 20:48:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXCc-0000v8-Dt for ram@iab.org; Mon, 02 Apr 2007 20:48:50 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXCb-0000RI-3T for ram@iab.org; Mon, 02 Apr 2007 20:48:50 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 17:48:48 -0700 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 l330mmiN020614; Mon, 2 Apr 2007 17:48:48 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l330mmZT007795; Tue, 3 Apr 2007 00:48:48 GMT Received: from xmb-sjc-218.amer.cisco.com ([171.70.151.151]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 17:48:48 -0700 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] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 17:48:45 -0700 Message-ID: <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> In-Reply-To: <46119E04.60107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1hlKi0HjhoCsbRA+8yVJQC/qwegAAuncw References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> From: "Darrel Lewis \(darlewis\)" To: "Russ White" , "Fleischman, Eric" X-OriginalArrivalTime: 03 Apr 2007 00:48:48.0352 (UTC) FILETIME=[D7200E00:01C77589] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1352; t=1175561328; x=1176425328; c=relaxed/simple; s=sjdkim4002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=bNLi6l7CCy+FcjoI3bf9NqLJlln6/IqqxM6F8B5nZzI=; b=N3Q9kD1eFGa6RvRdXe08F9sFQbhD80PuvF5f3MDJNdZvl+fhNhn+AYdcYosWygNx8QUf4DRY s3KyiDzsl7m7Alp7gvyW0zXp0BCyogxnw/tgLi9D+my29v5WmOTSHfyA; Authentication-Results: sj-dkim-4; header.From=darlewis@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 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 Russ White wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 >=20 >=20 >> Yes!!! I fully agree. LISP offers this promise. Whatever the IETF >> finally chooses also needs to do this, if we are going to finally >> have a realistic (non-mythical) architecture. >=20 > What gain would an Enterprise be able to point to if they > deployed LISP at their internal edge routers? >=20 > 1. They made their internal routing tables smaller. They > weren't big to begin with. >=20 > 2. They reduced the churn in their routing tables, and, most > likely, increased the churn in some other table. >=20 > 3. They added more software and, quite possibly, boxes to support it. >=20 > 4. They made their ISP's tables smaller. Big deal. >=20 > If I'm an Enterprise customer, why am I buying this? I'm > certainly cementing the current business model of the > Internet in place, but I'm not certain that buys me much of anything, > either, does it?=20 >=20 As an enterprise, having PI space instead of PA space is a huge win. Why do you think that there is so much pressure on the regestries to provide PI space right now? LISP with real PI ID space allows me to handle two huge issues: 1) merging of enterprise networks, and 2) provider independence. These advantages seem pretty obvious to me, am I missing something? -D _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:55:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXJA-0003z9-9Q; Mon, 02 Apr 2007 20:55:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXJ9-0003z4-8E for ram@iab.org; Mon, 02 Apr 2007 20:55:35 -0400 Received: from xmail04.myhosting.com ([168.144.250.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXJ7-0002gj-TW for ram@iab.org; Mon, 02 Apr 2007 20:55:35 -0400 Received: (qmail 2670 invoked from network); 3 Apr 2007 00:55:33 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 00:55:32 -0000 Message-ID: <4611A5B6.1020407@cisco.com> Date: Mon, 02 Apr 2007 20:54:14 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 >> What gain would an Enterprise be able to point to if they deployed LISP >> at their internal edge routers? > > - The ability to change service providers without affecting internal hosts. They already have this. > - Not having to convince/pay the enterprise's service provider(s) to > route an additional PI prefix (the ISP-size of the edge would, of > course, be provider aggregatable). Which SP is, today, refusing to accept business by way of refusing to advertise PI space? I don't know of any, myself. For the most part, providers are in business to make money, and paying customers are hard to turn away. To the contrary, I know of several large customers who have gone to PI space specifically because they could not get non-PI space from their providers. > Note that since end point identifiers do not need to be aggregatable for > routing purposes, there is no reason they need to be allocated > hierarchically. As such, alternative allocation models could be used. > Not sure this is a benefit, but thought I'd mention it. This just transfers the problem from the routing table to some other table--it doesn't solve the problem, in any way. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEaW2ER27sUhU9OQRAt4fAJ0exieksljBBZxGXOCoo7sf0gzo0ACeIgPL ynU3swBNZ6bq5r0pqyB52uM= =tUCy -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 20:59:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXML-00085E-09; Mon, 02 Apr 2007 20:58:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXMJ-00084w-4J for ram@iab.org; Mon, 02 Apr 2007 20:58:51 -0400 Received: from xmail04.myhosting.com ([168.144.250.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXMH-00047X-SU for ram@iab.org; Mon, 02 Apr 2007 20:58:51 -0400 Received: (qmail 9947 invoked from network); 3 Apr 2007 00:58:49 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail04.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 00:58:49 -0000 Message-ID: <4611A67A.2020209@cisco.com> Date: Mon, 02 Apr 2007 20:57:30 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Darrel Lewis (darlewis)" Subject: Re: [RAM] LISP and the Global Internet Architecture References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> In-Reply-To: <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: "Fleischman, Eric" , 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 > As an enterprise, having PI space instead of PA space is a huge win. > Why do you think that there is so much pressure on the regestries to > provide PI space right now? LISP with real PI ID space allows me to > handle two huge issues: 1) merging of enterprise networks, and 2) > provider independence. These advantages seem pretty obvious to me, am I > missing something? What do I get over just deploying PI space? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEaZ6ER27sUhU9OQRAqGNAJ45IzkVP+9pbAWA1xNT5DF6oJv86wCg/Bh1 wjdzafd/n0y42t/bOhFzeVo= =FWrb -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 21:10:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXWD-0007RB-Nf; Mon, 02 Apr 2007 21:09:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXWD-0007R6-2o for ram@iab.org; Mon, 02 Apr 2007 21:09:05 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXWB-0007Dv-Tc for ram@iab.org; Mon, 02 Apr 2007 21:09:05 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 73A5B872CE; Mon, 2 Apr 2007 21:09:01 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] LISP and the Global Internet Architecture Message-Id: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> Date: Mon, 2 Apr 2007 21:09:01 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: Russ White >> LISP with real PI ID space allows me to handle two huge issues: 1) >> merging of enterprise networks, and 2) provider independence. ... >> What do I get over just deploying PI space? > What do I get over just deploying PI space? As a customer, nothing. It's not the customers who are going to bear the pain of widespread PI, it's the ISP's. Which is why it makes sense to have a jack-up solution that only the ISP's have to deploy - they are the ones who will benefit, so they are the ones who have the incentive to actually do it. And that's also why it makes sense to have a jack-up solution which is completely invisible to customers (including their routers), because deploying it buys them nothing. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 21:10:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXVZ-0006R7-36; Mon, 02 Apr 2007 21:08:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXVX-0006Ph-H1 for ram@iab.org; Mon, 02 Apr 2007 21:08:23 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXVV-00071o-8D for ram@iab.org; Mon, 02 Apr 2007 21:08:23 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 02 Apr 2007 18:08:17 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3318H3q025053 for ; Mon, 2 Apr 2007 18:08:17 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3318FA8009106 for ; Tue, 3 Apr 2007 01:08:17 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 18:08:37 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=549; t=1175562497; x=1176426497; c=relaxed/simple; s=sjdkim6002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=xRWpgKNQsRGitO1dBJ+X3hsRXhC7pAsZ5iqZhuwlqno=; b=oHafHlG96ydcWM6Vuh8YUjPbSmhjt9cMBQx3DbfuxMLqc5RZTRr3eK8P8YxoGEq/g2bphX0l z9063O6gd7U97lDuXlMh/v7YcDR9m9sEs+xPnpypZDGiPiHHfaQ/rjib; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 2, 2007, at 5:48 PM, Darrel Lewis ((darlewis)) wrote: > 1) merging of enterprise networks This is certainly a potential benefit of a LISP-like architecture - a way to avoid address-space collision, dual NATs, etc. It's also a useful potentially useful concept for a transitional mechanism. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 21:18:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXf5-0005Ke-U3; Mon, 02 Apr 2007 21:18:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXf3-0005KU-Sd for ram@iab.org; Mon, 02 Apr 2007 21:18:13 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXf2-00011P-JX for ram@iab.org; Mon, 02 Apr 2007 21:18:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 02 Apr 2007 18:18:12 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l331ICnF020976; Mon, 2 Apr 2007 18:18:12 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l331IBEi018491; Tue, 3 Apr 2007 01:18:11 GMT 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, 2 Apr 2007 18:18:11 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 18:18:11 -0700 In-Reply-To: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> References: <20070403010901.73A5B872CE@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: <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 18:18:09 -0700 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 01:18:11.0072 (UTC) FILETIME=[F1C9C800:01C7758D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=372; t=1175563092; x=1176427092; c=relaxed/simple; s=sjdkim1004; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=RfENqd7n1SOrSZhDQEP0pJm7mWhNlASlyCt6Ukw4Nok=; b=rYKnXobwEx2t51KcLdfTMWChWwYiKxPjx2nup9Hia/yDrhUlm0Ptuq5EHWV3MIoU70gnLxpj xeJvI+0akfAfg7Kw94TulBl0w+2oPG4PNoV5XmeUQH3khkmTbB/tL4+QiGgS9jO/Knml7IkSjD N1XdocoJGjmlc63lQSmbUn7uc=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 do I get over just deploying PI space? > > As a customer, nothing. It's not the customers who are going to > bear the > pain of widespread PI, it's the ISP's. Hopefully, we will get to the point where identifiers are easier to justify and use than PI space. One possible mechanism for this is for providers to stop routing PI space... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 21:22:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXie-00075L-FW; Mon, 02 Apr 2007 21:21:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXic-00075G-QA for ram@iab.org; Mon, 02 Apr 2007 21:21:54 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXib-0001Rs-8K for ram@iab.org; Mon, 02 Apr 2007 21:21:54 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l3318361035535; Mon, 2 Apr 2007 18:08:04 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Mon, 02 Apr 2007 18:21:41 -0700 X-PGP-Universal: processed; by terminus.local on Mon, 02 Apr 2007 18:21:41 -0700 In-Reply-To: <4611A5B6.1020407@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <4611A5B6.1020407@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 18:21:39 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa 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 Russ, On Apr 2, 2007, at 5:54 PM, Russ White wrote: >>> What gain would an Enterprise be able to point to if they >>> deployed LISP >>> at their internal edge routers? >> >> - The ability to change service providers without affecting >> internal hosts. > They already have this. > >> - Not having to convince/pay the enterprise's service provider(s) to >> route an additional PI prefix (the ISP-size of the edge would, of >> course, be provider aggregatable). > > Which SP is, today, refusing to accept business by way of refusing to > advertise PI space? You removed the part where I tied the two together, specifically: >> However, as the routing system bloats, I suspect the latter >> benefit will come more and more into play. The whole RAM discussion was initiated in part because some large ISPs looked into their crystal ball and got nervous about how quickly routing information was being generated. When they also looked at their favorite routing vendors product roadmaps, they got more nervous. And then some smart people looked at trends in routing hardware manufacturing, power consumption, heat dissipation, etc. and suggested that "Houston, we have a problem." Maybe both the folks at large ISPs and the various smart people are wrong. If you make the assumption that "every edge gets PI" can and will scale until we deploy IPv7 (as some on the IAB have done), then the problem magically goes away (since it never really existed). However, if you are not comfortable in making that sort of assumption, then you have to start looking for operationally deployable solutions. You a betting man? :-) Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 21:22:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXjO-0000OS-TW; Mon, 02 Apr 2007 21:22:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXjN-0000ON-3F for ram@iab.org; Mon, 02 Apr 2007 21:22:41 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXjK-0001fd-Ot for ram@iab.org; Mon, 02 Apr 2007 21:22:41 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 18:22:40 -0700 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 l331Mcnx025328; Mon, 2 Apr 2007 18:22:38 -0700 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 l331McMF014691; Tue, 3 Apr 2007 01:22:38 GMT 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); Mon, 2 Apr 2007 18:22:38 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 18:22:37 -0700 In-Reply-To: <4611A5B6.1020407@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <4611A5B6.1020407@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7E51D495-21DB-4213-B8D9-FC08DB117313@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 18:22:36 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 01:22:37.0712 (UTC) FILETIME=[90B7D100:01C7758E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=732; t=1175563358; x=1176427358; c=relaxed/simple; s=sjdkim3002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=Zot2FHmx8TD2b3MsVQlKznFwcGJjCz1S7HtWBPYtA7Q=; b=DW+btwy0boc1tvL77KkQWxISUQ6ArXkNdZ++si89MGs8TfXMDGHkZ76lZ2ox71K+r0pf28Cg H71T3Qy7pzHF4K8hu/1DdSwa7OcSse3aI4sJGzCn1RjC2ms6WmCzSoDD; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Apr 2, 2007, at 5:54 PM, Russ White wrote: >> Note that since end point identifiers do not need to be >> aggregatable for >> routing purposes, there is no reason they need to be allocated >> hierarchically. As such, alternative allocation models could be >> used. >> Not sure this is a benefit, but thought I'd mention it. > > This just transfers the problem from the routing table to some other > table--it doesn't solve the problem, in any way. This is simply incorrect. Moving the problem from the RIB/FIB to a partially populated cache at a much lower access rate does solve the problem: the costs for such equipment will be borne directly and solely by the people on the data path. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 21:30:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXqi-0004Wk-Dg; Mon, 02 Apr 2007 21:30:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYXqg-0004W0-UX for ram@iab.org; Mon, 02 Apr 2007 21:30:14 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYXpN-0002V3-Ng for ram@iab.org; Mon, 02 Apr 2007 21:28:55 -0400 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 6440592; Mon, 02 Apr 2007 21:28:49 -0400 In-Reply-To: <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.com> References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.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: Marshall Eubanks Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 21:28:44 -0400 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: Noel Chiappa , 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 Apr 2, 2007, at 9:18 PM, Tony Li wrote: > >>> What do I get over just deploying PI space? >> >> As a customer, nothing. It's not the customers who are going to >> bear the >> pain of widespread PI, it's the ISP's. > > > Hopefully, we will get to the point where identifiers are easier to > justify and use than PI space. One possible mechanism for this is > for providers to stop routing PI space... > Won't that be a faster mechanism to get their customers to stop paying them ? In the back of my mind I can hear Randy Bush saying something. > Tony Regards Marshall > > _______________________________________________ > 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 Apr 02 21:50:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYY9W-0007m5-D1; Mon, 02 Apr 2007 21:49:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYY9U-0007lu-8G for ram@iab.org; Mon, 02 Apr 2007 21:49:40 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYY9S-0006jd-Uv for ram@iab.org; Mon, 02 Apr 2007 21:49:40 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 02 Apr 2007 18:49:39 -0700 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 l331ncGa006518; Mon, 2 Apr 2007 18:49:38 -0700 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 l331ncZT012551; Tue, 3 Apr 2007 01:49:38 GMT 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, 2 Apr 2007 18:49:37 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 2 Apr 2007 18:49:37 -0700 In-Reply-To: References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.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: Tony Li Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 18:49:35 -0700 To: Marshall Eubanks X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 01:49:37.0306 (UTC) FILETIME=[56123FA0:01C77592] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=314; t=1175564978; x=1176428978; c=relaxed/simple; s=sjdkim2002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=WGWD0z8n4kzt8n7Uh40yntUqhkCMSbuN3LzzojR5OnA=; b=LV5qIGFzzo9qH361lbo8Byeq5sAPaROv6jR53kToj94Zdp07prjzyFjsPvV5IePOATCn7pDA 4QOGPlXVkQoUNxQfWbypksYBtNw6JkI5ddufaidHCQ/ie4mMmYsxyaRI; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: Noel Chiappa , 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 Apr 2, 2007, at 6:28 PM, Marshall Eubanks wrote: > Won't that be a faster mechanism to get their customers to stop > paying them ? Not if it doesn't impact connectivity. > In the back of my mind I can hear > Randy Bush saying something. You should see a doctor about that. ;-) Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 22:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYRi-0008Bi-1L; Mon, 02 Apr 2007 22:08:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYRg-0008BT-Ja for ram@iab.org; Mon, 02 Apr 2007 22:08:28 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYRe-00028B-BY for ram@iab.org; Mon, 02 Apr 2007 22:08:28 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id D4A4F872DD; Mon, 2 Apr 2007 22:08:25 -0400 (EDT) To: ram@iab.org Subject: RE: [RAM] LISP and the Global Internet Architecture Message-Id: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> Date: Mon, 2 Apr 2007 22:08:25 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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: "Fleischman, Eric" > until IPv6 permitted PI addresses, it represented a mechanism that > required large end users to be held captive to their ISPs. This is > untenable to any end user and violates a fundamental law of economics > that businesses support the needs of their customers. This was certainly not the intent, or reason, that location-based addressing was put forward; rather, it was principally motivated by technical considerations. ("PA" is just a post-hoc label applied to something that came from technical considerations, hence its original names - "location-based addressing" or "connectivity-based addressing".) You are correct that it had economic consequences that either weren't adequately considered, or taken into account (or perhaps both), at the time. I think the whole IPv6 experience (and not just the PA/PI thing) has made us all much more sensitive to the need to try and understand the economics of the proposed deployment of any new stuff. Which leads me to wonder what the future really is, though. What happens when the IPv4 addresses really do start to run out in a few years? Will we see a market develop for IPv4 addresses, plus continued use of NAT? Or will uSoft's attempt to drive IPv6 deployment by including it in Vista succeed? And even more importantly, is there really any scope left for good fundamentals-based engineering, or will we always be restricted by economic/business considerations to the cheapest thing we can possibly come up with that more or less kludges the network into continued operation? Maybe it's time to switch out of networking (or just plain retire and take up building furniture :-). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 02 22:31:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYmZ-0006u0-0h; Mon, 02 Apr 2007 22:30:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYYmX-0006tb-GL for ram@iab.org; Mon, 02 Apr 2007 22:30:01 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYYmT-0006C2-5g for ram@iab.org; Mon, 02 Apr 2007 22:30:01 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id D363C59E55; Tue, 3 Apr 2007 12:29:54 +1000 (EST) Message-ID: <4611BC16.7090904@firstpr.com.au> Date: Tue, 03 Apr 2007 12:29:42 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Cc: Subject: [RAM] LISP etc. is not the only path to scalable routing 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 David Conrad wrote (Re: [LISP and the Global Internet Architecture): > IPv6, as defined, is little more than IPv4 with more bits. As lots of > people pointed out lots of times, the size of the address wasn't really > the problem, rather the scalability of the routing system was. We're > now trying to come up with a solution to the scalability problem that > doesn't involve "use more thrust". LISP and its ilk are the first > realistic attempts to actually deal with scaling the Internet up. This may be so. In that case perhaps the SRAM-mapped FIB approach: http://www.ietf.org/internet-drafts/draft-whittle-sram-ip-forwarding-01 is the second. There have been well over a hundred messages on this list since I wrote about my SRAM-based forwarding draft - all of them concerning LISP. I know it takes a while to read my draft, but the idea is simple. I hope that there will be some discussion of it in the next few weeks. I am concerned that people in this field have spent so long - a decade or more - assuming that route aggregation must always be maximised, that they will find it hard to imagine all the benefits of tens or hundreds of thousands of AS end-users and ISPs being able to advertise PI addresses. The SRAM approach handles millions of separately advertised /24s - without any regard to topology and without burdening anyone, other than with the burden of BGP traffic and router CPU load for each change. A single Static RAM chip can be installed in each interface of future DFZ routers, taking 4 nsec to map every one of the 14,680,064 /24s to its own Forwarding Equivalent Class (which interface to send the packet to). As long as the /24 BGP limit remains, this completely solves the hardware scaling issues of IPv4 routing in terms of actually handling the packets, which is the most difficult task. The same chip can handle IPv6, within some limits which would need to be carefully decided. A single 72 Mbit chip in each interface, (or two for larger routers) provides single-cycle packet forwarding for: IPv4: The entire space of 3.7 billion IP addresses in 14 million prefixes. IPv6: (for instance) 17 billion /48 user networks advertised as 2 million /35 prefixes - each with 8192 /48 user networks. without any extra delay, complication or power consumption even if every prefix was advertised separately to create worst-case route disaggregation. This means that there is no problem (for the FIB function of these routers) in giving large numbers of AS end-users Provider Independent addresss for both IPv4 and IPv6. This is not a case of "using more thrust". It is a simpler and more elegant technique than TCAM and tree-structured memory lookups, which has not been possible in the past because the SRAM chips were not big enough. Now these chips are in production, and since the routers in the DFZ are all going to need replacement in 5 to 7 years due to the growth in the BGP routing table anyway, I think it will be perfectly feasible (say in 2014) to have a DFZ with 14 million IPv4 routes - *if* BGP and the router's CPUs can handle the required communications. As long as AS end-users are not changing the way they advertise prefixes on an hourly, or even daily basis - meaning they only change the global BGP routing table when they change their ISP (including in rare instances of failure) - then I imagine the BGP routing system will cope, as long as routers have somewhat faster CPUs and more memory. My understanding of instability in BGP is that it only affects the prefixes which are being changed. So if one AS end-user changes the router which one or more of their prefixes are advertised on, and if it takes the global system some time to propagate this, then it is a cost they alone bear. I understand that flap damping is intended to reduce the propagation of rapid changes, so if this is extended in some agreed manner to discourage recurrent, frequent - and therefore presumably deliberate - changes, then the load on the BGP system should not be too high. Most of the load at present is with long prefixes and probably "badly managed" systems - at least according to the interests of those who run DFZ routers. http://bgpupdates.potaroo.net/instability/bgpupd.html "Adds and Wdls per Prefix Length" at: http://www.cidr-report.org shows the great majority of changes are for /22, /23 and /24 prefixes. /16 +20 -21 /17 +23 -13 /18 +40 -23 /19 +82 -80 /20 +115 -82 /21 +159 -124 /22 +226 -131 /23 +297 -177 /24 +1302 -1085 /25 +0 -0 Yet these cover only 0.85% of the advertised address space, and (according to my ping survey, which only gives some indication) they don't appear to have particularly high rates of address utilisation. There is a graphic at: http://www.firstpr.com.au/ip/ One problem with assigning PI space to many more smaller AS end-users is that many more smaller prefixes will probably be poorly managed. With the direct mapped SRAM-FIB, there is no problem with where they advertise the prefixes, or how many they advertise. However the router CPU and RAM of all the DFZ routers need to cope with the number, and with the rate of changes. The SRAM-based approach does not provide seamless connectivity for TCP etc. when changing the prefix to another router. Some disruption would occur - but it would not disrupt other prefixes. It would fully support basic multihoming for redundancy when an ISP fails. It could support rapid changes for time-of-day sensitive traffic management, as long as the BGP system could handle it, which I suspect it can't or shouldn't have to. There would be moderately "more thrust" in the CPU and memory area, but the single SRAM chip is vastly lest thrustful than the current TCAM etc. approaches to hardware forwarding, especially if those approaches were scaled to handle millions of routes. Those TCAM etc. systems would remain, to handle routes longer than /24 (as flagged with a special value of FEC in the SRAM), and to handle other types of packet. All IPv4 unicast packets (and IPv6 unicast packets within the defined address range) would be handled by the SRAM system, which would correctly classify all the user traffic. TCAM etc. would also be used for the complex needs of border and internal routers, but there would not need to be much TCAM in DFZ transit routers - probably only enough to handle the prefixes used for router-to-router traffic. Maybe that traffic would be low enough to handle with the CPU, so pure transit routers might not need TCAM at all. Whereas TCAM etc. can require lengthy rewrites (during which it can't classify packets), to rearrange many of the rules when a single route is added, the SRAM-FIB approach can be updated quickly with one or more writes, since there is no need to rearrange the data which implements the rules for other prefixes. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 00:29: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 1HYabZ-0006cD-PE; Tue, 03 Apr 2007 00:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYabY-0006by-K4 for ram@iab.org; Tue, 03 Apr 2007 00:26:48 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYabW-000176-Cf for ram@iab.org; Tue, 03 Apr 2007 00:26:48 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2007 00:26:48 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l334QkoQ029914; Tue, 3 Apr 2007 00:26:46 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l334QXGd011964; Tue, 3 Apr 2007 04:26:33 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 00:26:33 -0400 Received: from [192.168.0.4] ([10.82.218.203]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 00:26:32 -0400 In-Reply-To: <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Mon, 2 Apr 2007 21:26:36 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 04:26:32.0843 (UTC) FILETIME=[422B2DB0:01C775A8] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=320; t=1175574406; x=1176438406; c=relaxed/simple; s=rtpdkim2001; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP] |Sender:=20 |To:=20Tony=20Li=20; bh=QJA492mdIFhjT0zvn0iEbdVme6ICEo9sWXZVjG/DK0E=; b=Ux3d6EzUBaXXZNrwerx0G2uQgE7er6nnRGW7bO3iOnsL7PyC0hQ8KfbSmNTmQ5VRdv4X0Nr4 Ko+ruWmpRRkOWxfiGYdf351C+r+pZa+ZlkjlDvamJeQrb08iH+OoI3zR; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: "Fleischman, Eric" , 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 > Aggregate-ability of locators is wholly irrelevant in a push model, > since the entire database must be distributed anyway. But is it one entry per site. It can be only if there are one set of locators per site. > Have we converged on only using a pull model for the mapping? I don't think so. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 00:44:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYara-0002oj-57; Tue, 03 Apr 2007 00:43:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYarZ-0002oe-4X for ram@iab.org; Tue, 03 Apr 2007 00:43:21 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYarX-0006qb-TL for ram@iab.org; Tue, 03 Apr 2007 00:43:21 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2007 00:43:20 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l334hJOb008795; Tue, 3 Apr 2007 00:43:19 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l334hJGd014654; Tue, 3 Apr 2007 04:43:19 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 00:43:19 -0400 Received: from [192.168.0.4] ([10.82.218.203]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 00:43:18 -0400 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A101774879@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><00F50713-B987-45E6-A7C8-75B65AAF8619@cisco.com><09FCBD08-6613-49D8-90C9-4B3AF4FA23EA@cisco.com> <4BE05A64-C9A1-458F-A162-F839E192B0A3@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774879@XCH-NW-7V2.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: <4572267C-4FBC-40DD-8F96-F0821E6A9158@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] locator/identifier assumptions Date: Mon, 2 Apr 2007 21:43:22 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 04:43:18.0968 (UTC) FILETIME=[99DDAB80:01C775AA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=718; t=1175575399; x=1176439399; c=relaxed/simple; s=rtpdkim1001; 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]=20locator/identifier=20assumptions |Sender:=20 |To:=20=22Templin,=20Fred=20L=22=20; bh=qRZKreoWDtnMKTGJ/Kn067v02F8us40ksfBrZziU7zA=; b=kjFY0vP43Wi7QeGgOubnU3fifat/myLZ7aR21CwFBC3xm6PLThSkSoBsc+MS3+M9zJLxJE8a MzJaYxO3sUE/+WsPhOsOhuXG50WHiMkHbN4z387RwUYPmbkXDYKmtKWt; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 have been operating under the following assumptions: > > 1) LISP 1 - locators and identifers are globally routable > IPv4 addresses. > 2) LISP 1.5 - locators are globally routable IPv4 addresses, > and identifiers are IPv6 addresses that are routeable on > a global IPv6 infrastructure, e.g., the 6Bone. > 3) LISP 2/3 - locators are globally routable IPv4 addresses, > and identifiers are IPv6 addresses that are routeable > only within the local enterprise/site. IPv6 ULAs (RFC4193) > provide a natural addressing mechanism for this. The spec indicates each variant can be used for IPv4 and IPv6. So one variant is not more IPv6 or IPv4 centric then the other. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 00:45:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYatU-0003lc-Dm; Tue, 03 Apr 2007 00:45:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYatS-0003lW-VO for ram@iab.org; Tue, 03 Apr 2007 00:45:18 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYatR-0007Sl-OQ for ram@iab.org; Tue, 03 Apr 2007 00:45:18 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 03 Apr 2007 00:45:18 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l334jH0a001847; Tue, 3 Apr 2007 00:45:17 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l334jHlG020545; Tue, 3 Apr 2007 04:45:17 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 00:45:17 -0400 Received: from [192.168.0.4] ([10.82.218.203]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 00:45:16 -0400 In-Reply-To: <200704022152.l32Lq1J08204@merlot.juniper.net> References: <200704022152.l32Lq1J08204@merlot.juniper.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] Incremental Deployment of LISP Date: Mon, 2 Apr 2007 21:45:20 -0700 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 04:45:16.0450 (UTC) FILETIME=[DFE40020:01C775AA] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=476; t=1175575517; x=1176439517; c=relaxed/simple; s=rtpdkim2001; 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]=20Incremental=20Deployment=20of=20LISP=20 |Sender:=20 |To:=20Yakov=20Rekhter=20; bh=b5b+QnzoB66mvhRwSGnTQODCpDYznSF/9uty0/GR8dM=; b=HZg6LYfH97HIb4t/JStVafvN2rP8zORNkaYjgWVlre450JZN6yyX8QdzHkbCCm6aJdl6OYPF NRUNmdfkk3ylMmCsAOu6q/Qh7Cp783pVu7KTN5m2aB0FGkOb73U6ysde; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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 would be an good example to illustrate that LISP 1.5 offer > *no* reduction of the volume of routing information. To the contrary, > this example would illustrate how LISP 1.5 would result in increasing > volume of routing information. It reduces the unicast FIB. And the number of routers that have to store the additional routes. Furthermore, the EID-prefix space can aggregate better than today's BGP core since it is not based on topology. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 02:03:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYc4S-0005rZ-O3; Tue, 03 Apr 2007 02:00:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYc4S-0005rU-6k for ram@iab.org; Tue, 03 Apr 2007 02:00:44 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYc4R-0003xN-00 for ram@iab.org; Tue, 03 Apr 2007 02:00:44 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2007 02:00:43 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3360gTC024778; Tue, 3 Apr 2007 02:00:42 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3360jGd026020; Tue, 3 Apr 2007 06:00:45 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 02:00:42 -0400 Received: from [192.168.0.4] ([10.82.218.133]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 02:00:42 -0400 In-Reply-To: <7E51D495-21DB-4213-B8D9-FC08DB117313@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <4611A5B6.1020407@cisco.com> <7E51D495-21DB-4213-B8D9-FC08DB117313@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <808E8BA2-7435-4E2F-A447-8F05B6C0CD77@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Mon, 2 Apr 2007 23:00:46 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 06:00:42.0196 (UTC) FILETIME=[69720940:01C775B5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=315; t=1175580042; x=1176444042; c=relaxed/simple; s=rtpdkim1001; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20 |To:=20Tony=20Li=20; bh=yncI98/Y21QChFa5wsBTtakC+nsf7VM01Usm3BDmdBM=; b=oCO1uRIOvUto9RsaN3BKhRiKN5mgWtJjFsYb4PU4i0VSKeIXqMI1+KkLkO0+BsFWycFMQmyL ldsqIOXUTMkYKvNEfcLS8dZMuJkCph/xnE3PL24V4YQ2w15RxwqTxNn+; Authentication-Results: rtp-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 simply incorrect. Moving the problem from the RIB/FIB to a > partially populated cache at a much lower access rate does solve > the problem: the costs for such equipment will be borne directly > and solely by the people on the data path. This is correct and the motivation for LISP. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 07:16:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgxq-0000jp-PX; Tue, 03 Apr 2007 07:14:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgxo-0000c1-Qh for ram@iab.org; Tue, 03 Apr 2007 07:14:12 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYguX-0002cJ-2B for ram@iab.org; Tue, 03 Apr 2007 07:10:51 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2007 13:10:38 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l33BAbXm026461; Tue, 3 Apr 2007 13:10:37 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp362.cisco.com [10.61.65.106]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33BAUlZ027623; Tue, 3 Apr 2007 11:10:33 GMT Message-ID: <46123624.50503@cisco.com> Date: Tue, 03 Apr 2007 13:10:28 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: David Conrad References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <46114E69.20901@cisco.com> <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> In-Reply-To: <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1749; t=1175598637; x=1176462637; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Scaling=20target |Sender:=20; bh=+ns/bu8mw5tyr6P6+WFydEmLbxiVuFhYj6ziH8iCG6g=; b=mnC7D5bSRStcNm6oh79RYz4awfgUHq+2DktCuS4KytbobkLywjMcvXMv0Cyq81Ap94gN8ciU csiYpdz0BTIckVUxjgl8bNSRkBTVpbZBPBTPxT/4dMKe7xm4wJSTlS3n; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ram@iab.org Subject: [RAM] Re: Scaling target 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 Dave, > My assumptions is that the mapping table will be approximately equal > to the number of network attachment edge points. That is, the end > state is that you have a locator numbered core interconnecting an > identifier numbered edge. The mapping service translates the > non-aggregatable identifier universe into the highly aggregateable > locator universe. I don't see why we should assume this. Take the common case where you have a gazillion residential DSL connections. Why don't they just continue to use the PA space and let the SPs handle any LISP. The PE or something close to it still needs to do LISP, but they need to do BGP today, so that doesn't particularly bother me IFF the update times on LISP are several orders of magnitudes below that of the routing space. > >> I imagine that each entry in this table saves some space somewhere in >> the RIB. I further envision that either big multihomed enterprise >> h/w or PE h/w will perform the mapping. > > Simplifying a bit, I am assuming at every service provider/customer > boundary (for some value of the variable "service provider"), there is > a mapping device (what Dino calls an ITR) and that each one of those > ITRs will require at least one mapping entry (more if they are > multi-homed, which I expect to become the norm as opposed to the > exception as more and more services depend on reliable IP service). > > The goal of the mapping is to ensure the RIB/FIB scales with the > number of service providers, not the number of network attachment edge > points. Nice goal. I do not see how we get there. This having been said, O(DSLAMs) seems considerably smaller than O(network attachment points). Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 07:16:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgyU-0001R2-2u; Tue, 03 Apr 2007 07:14:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYgxq-0000dC-SM for ram@iab.org; Tue, 03 Apr 2007 07:14:14 -0400 Received: from mtagate4.de.ibm.com ([195.212.29.153]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYgts-0002Tn-Rh for ram@iab.org; Tue, 03 Apr 2007 07:10:10 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l33BA7Sw077820 for ; Tue, 3 Apr 2007 11:10:07 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l33BA6Qx1912944 for ; Tue, 3 Apr 2007 13:10:07 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l33BA6tj011075 for ; Tue, 3 Apr 2007 13:10:06 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l33BA5Gs011060; Tue, 3 Apr 2007 13:10:05 +0200 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA189476; Tue, 3 Apr 2007 13:10:04 +0200 Message-ID: <4612360C.2090704@zurich.ibm.com> Date: Tue, 03 Apr 2007 13:10:04 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> In-Reply-To: <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Tony Li , "Fleischman, Eric" , 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-04-03 06:26, Dino Farinacci wrote: >> Aggregate-ability of locators is wholly irrelevant in a push model, >> since the entire database must be distributed anyway. > > But is it one entry per site. It can be only if there are one set of > locators per site. > >> Have we converged on only using a pull model for the mapping? > > I don't think so. Nor me. I think we should consider this as a whole separate topic from the LISP model as such. It seems to me that every solution we've talked about that is even vaguely in the id/loc split space calls for an id/loc mapping service, so we should consider it as an orthogonal matter. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 07:23:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYh6P-0008LB-IH; Tue, 03 Apr 2007 07:23:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYh6N-0008J4-Pd for ram@iab.org; Tue, 03 Apr 2007 07:23:03 -0400 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYh6M-00062N-AP for ram@iab.org; Tue, 03 Apr 2007 07:23:03 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l33BN1hM053756 for ; Tue, 3 Apr 2007 11:23:01 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l33BN1322654306 for ; Tue, 3 Apr 2007 12:23:01 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l33BN07u012413 for ; Tue, 3 Apr 2007 12:23:01 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l33BN0Mv012402; Tue, 3 Apr 2007 12:23:00 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA299874; Tue, 3 Apr 2007 13:22:58 +0200 Message-ID: <46123912.7080300@zurich.ibm.com> Date: Tue, 03 Apr 2007 13:22:58 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Re: ICMP error dependency in LISP References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <7F4A2742-026B-4F7E-9A1A-6CD07808BB1E@thingmagic.com> <7DD493A6-5309-4592-9558-316C75F66494@cisco.com> <96C5E0BB-831A-4824-8F04-535379A25B38@cisco.com> <4610BF94.7090508@zurich.ibm.com> <5C4EDAB9-F601-4936-8B13-E412923BF7E1@cisco.com> In-Reply-To: <5C4EDAB9-F601-4936-8B13-E412923BF7E1@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Cc: Margaret Wasserman , 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-04-02 19:33, Dino Farinacci wrote: >>> The Internet is best-effort, we are not trying to make datagram >>> delivery more reliable. If a EID mapping has multiple locators and >>> the ETR indicates the priority of each locator is the same, the ITR >>> can load-split traffic among the locators. >> >> That raises the spectre of out-of-order delivery, which can be very >> painful for the transport layer. > > A traditional tradeoff between route-based versus flow-based forwarding. > And the decent middle ground adopted today is hashing. > > So for an EID-prefix match, you hash on the 4-tuple say, and then pick a > Locator (and stick with it) from the Locator-set. Yes, any trick that allows reasonable in-orderness per flow is fine. > > Brian, don't worry, be happy. ;-) I try :-) > >>>> d) some poor firewall or ACL filters out the ICMP message at the ICMP >>>> originator's domain, in transit, or at the recipient's domain? >>> The protocol needs feedback. If you choose UDP to return the mapping >>> or error message, those could get filtered as well. There is no magic >>> here, you have to fix the filters. >> >> Well, I have to ask the same question I recently asked about shim6 >> error messages: will lost ICMP packets break the protocol? If yes, >> then I think that signalling in-band (i.e. in packets that are part >> of the target session) is much preferable. "Fix the filters" isn't >> a deployable feature of LISP, IMHO, because different people control the >> filters. > > Then you forward into black-holes. That tends to get people's attention > to get the problem fixed. But that's my point. This sort of thing *doesn't* get the attention of the right people, because it affects Joe Citizen, whose only recourse is an ISP (or corporate) help desk. You know how devoted they are to fixing 3rd party connectivity issues. I believe we have an iceberg shaped problem today of black holes caused by NAT nastiness, which are never identified as such, and I don't think we should create more of that sort of thing. > > There is no silver bullet here Brian. You know that, you've been doing > this too long as well. ;-) Yes. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 07:40:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhMh-000686-R8; Tue, 03 Apr 2007 07:39:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhMg-00067x-DO for ram@iab.org; Tue, 03 Apr 2007 07:39:54 -0400 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYhMf-0000m6-0I for ram@iab.org; Tue, 03 Apr 2007 07:39:54 -0400 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 l33Bdpxk169406 for ; Tue, 3 Apr 2007 11:39:51 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.3) with ESMTP id l33Bdp2O2654424 for ; Tue, 3 Apr 2007 13:39:51 +0200 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 l33Bdont030860 for ; Tue, 3 Apr 2007 13:39:51 +0200 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 l33BdoQ5030853; Tue, 3 Apr 2007 13:39:50 +0200 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA224684; Tue, 3 Apr 2007 13:39:50 +0200 Message-ID: <46123D06.6050006@zurich.ibm.com> Date: Tue, 03 Apr 2007 13:39:50 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <461148F8.4050804@cisco.com> <283DFE02-6396-43B9-92B3-E6C6DEF1ADEC@virtualized.org> <8DAC789F-339D-4096-9640-A6FFF0A5DDF1@cisco.com> In-Reply-To: <8DAC789F-339D-4096-9640-A6FFF0A5DDF1@cisco.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-04-02 20:49, Roland Dobbins wrote: > > On Apr 2, 2007, at 11:44 AM, David Conrad wrote: > >> Thus, the latency hit would occur only the first time the router sees >> the destination end point identifier or when the mapping has been >> dumped from the cache. > > What about dynamism on the part of the destination endpoint and/or > communications models which involve dynamic multiple destination endpoints? You're in extreme danger of reinventing shim6. The choice there was to send the packet and defer the mapping - which of course assumes the ID can be used as a locator. Strangely enough, LISP 1.0 seems to assume the same... Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 07:56:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhcD-0005y7-GS; Tue, 03 Apr 2007 07:55:57 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhcC-0005xw-Kw for ram@iab.org; Tue, 03 Apr 2007 07:55:56 -0400 Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYhc6-0002nn-RA for ram@iab.org; Tue, 03 Apr 2007 07:55:56 -0400 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 l33Btlvm139398 for ; Tue, 3 Apr 2007 11:55:47 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l33BtkZH2334846 for ; Tue, 3 Apr 2007 12:55:47 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l33BtjlH020944 for ; Tue, 3 Apr 2007 12:55:45 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l33Btj5T020930; Tue, 3 Apr 2007 12:55:45 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id NAA224626; Tue, 3 Apr 2007 13:55:44 +0200 Message-ID: <461240C0.8040100@zurich.ibm.com> Date: Tue, 03 Apr 2007 13:55:44 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Roland Dobbins Subject: Re: [RAM] LISP and the Global Internet Architecture References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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-04-03 03:08, Roland Dobbins wrote: > > On Apr 2, 2007, at 5:48 PM, Darrel Lewis ((darlewis)) wrote: > >> 1) merging of enterprise networks > > This is certainly a potential benefit of a LISP-like architecture - a > way to avoid address-space collision, dual NATs, etc. Except that with IPv6, you need neither LISP nor internal NATs to merge address spaces. As has been observed, the main win in IPv6 is having enough address space, so that collision isn't an issue and NAT isn't a requirement. The ability to change ISPs without excessive cost is harder, since nobody likes renumbering. Again, it isn't an issue for IPv6 sites big enough to procure PI space. And I wonder how many SMBs would really see renumbering a few printers as a major cost, if they had to use PA space instead of Net 10? I still see multihoming and TE as the main economic drivers here. > > It's also a useful potentially useful concept for a transitional mechanism. From what to what? Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 08:06:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhlw-0001eG-Pb; Tue, 03 Apr 2007 08:06:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYhlv-0001eB-Ev for ram@iab.org; Tue, 03 Apr 2007 08:05:59 -0400 Received: from p130.piuha.net ([193.234.218.130]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYhlu-0004CC-3p for ram@iab.org; Tue, 03 Apr 2007 08:05:59 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 8C4CE19869D; Tue, 3 Apr 2007 15:05:54 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 47B9119869C; Tue, 3 Apr 2007 15:05:54 +0300 (EEST) Message-ID: <46124322.2040102@piuha.net> Date: Tue, 03 Apr 2007 15:05:54 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] LISP and the Global Internet Architecture References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> In-Reply-To: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> 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: 79899194edc4f33a41f49410777972f8 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 Noel, > Which is why it makes sense to have a jack-up solution that only the ISP's > have to deploy - they are the ones who will benefit, so they are the ones > who have the incentive to actually do it. And that's also why it makes > sense to have a jack-up solution which is completely invisible to customers > (including their routers), because deploying it buys them nothing. > Indeed. And invisible to their hosts, too. And as we discussed in the other thread, as invisible as possible to their DNS operation, application behaviour, startup delays, etc... (The other side of this argument is this may not be the only improvement that is needed in the Internet, as the other parts may also need new things. But the jack-up seems like a good match for the routing problem, assuming we can work out the details, mapping schemes, etc.) Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 08:26:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYi3o-0007RA-Oq; Tue, 03 Apr 2007 08:24:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYi3n-0007R4-5d for ram@iab.org; Tue, 03 Apr 2007 08:24:27 -0400 Received: from xmail09.myhosting.com ([168.144.250.252]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYi3l-0002Ak-SR for ram@iab.org; Tue, 03 Apr 2007 08:24:27 -0400 Received: (qmail 27523 invoked from network); 3 Apr 2007 12:24:15 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail09.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 12:24:14 -0000 Message-ID: <4612471F.9070504@cisco.com> Date: Tue, 03 Apr 2007 08:22:55 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] LISP and the Global Internet Architecture References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> In-Reply-To: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 > >> LISP with real PI ID space allows me to handle two huge issues: 1) > >> merging of enterprise networks, and 2) provider independence. ... > >> What do I get over just deploying PI space? > > > What do I get over just deploying PI space? > > As a customer, nothing. It's not the customers who are going to bear the > pain of widespread PI, it's the ISP's. > > Which is why it makes sense to have a jack-up solution that only the ISP's > have to deploy - they are the ones who will benefit, so they are the ones > who have the incentive to actually do it. And that's also why it makes > sense to have a jack-up solution which is completely invisible to customers > (including their routers), because deploying it buys them nothing. Let's start by saying it's not a given that an ISP edge deployment really gains us anything. Given that it does, however.... LISP won't be invisible to customers even if you only deploy it at the ISP edge.... Enterprises might not see the additional equipment, but they will see the impact in two other areas: o They will no longer have any control over their inbound traffic flows. They have precious little control now, but will lose what control they have under LISP. I believe, in fact, this is one of the points of LISP. o They will see the results of the "tunnel wars" between providers trying to "out traffic engineer" their competitors, in terms of highly variable delay times, etc. o They will see the impact as providers fight with each other to have the various content providers either map their space into the service provider's tunnel endpoint space, to build traffic, or out of the service provider's tunnel endpoint space, to reduce traffic. Of course, the most likely result will be a rash of lawsuits over control of the "mapping tables," generated by LISP, which will then come down to minute control over who maps what where based in law and court cases. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEkcfER27sUhU9OQRAqQHAJwPlCaXUXCyiJKJIHPw6ScJlsXohgCg2C97 8HqhyQGZFYXmIDJk+a+R8g8= =TTUl -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 08:32: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 1HYiBb-0003nR-Lj; Tue, 03 Apr 2007 08:32:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiBZ-0003nG-O2 for ram@iab.org; Tue, 03 Apr 2007 08:32:29 -0400 Received: from xmail10.myhosting.com ([168.144.250.47]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYiBO-0003vu-T6 for ram@iab.org; Tue, 03 Apr 2007 08:32:29 -0400 Received: (qmail 19384 invoked from network); 3 Apr 2007 12:32:18 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail10.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 12:32:17 -0000 Message-ID: <46124902.5030608@cisco.com> Date: Tue, 03 Apr 2007 08:30:58 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Tony Li Subject: Re: [RAM] LISP and the Global Internet Architecture References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.com> In-Reply-To: <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: Noel Chiappa , 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 >>> What do I get over just deploying PI space? >> >> As a customer, nothing. It's not the customers who are going to bear the >> pain of widespread PI, it's the ISP's. > > > Hopefully, we will get to the point where identifiers are easier to > justify and use than PI space. One possible mechanism for this is for > providers to stop routing PI space... When providers stop accepting checks for connections to known spammers, I'll have more confidence they have the discipline to not route PI space. The actual sequence of events is likely to be: 1. LISP 1 deploys. This increases the sizes of the tables held, increases churn, and causes a few dozen technical problems no-one thought of. It causes major heartache for large enterprise customers and content providers, so a number of them get an "opt out" from their providers so their p-loc/p-id mappings are 1-to-1 direct, or "special consideration" in the placement of p-loc/p-id mappings in the various tables (all for a cost, of course). 2. LISP 1.5, 1.78, 1.912455, 2.0, 3.0, and 19.0 never deploy, the providers having gotten what they wanted in a new revenue stream, and a way to traffic engineer through and around their competitors with no manual tunnel setup. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEkkCER27sUhU9OQRArz+AKCUm6Wpqjf/JYXpaeHNXy9VYn6AqgCggEKa RS+2UrgrY+1TpTI+X/KuvgA= =8Wrv -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 08:38:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiGt-0000tI-SA; Tue, 03 Apr 2007 08:37:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiGs-0000tC-1y for ram@iab.org; Tue, 03 Apr 2007 08:37:58 -0400 Received: from xmail03.myhosting.com ([168.144.250.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYiGq-00051k-PN for ram@iab.org; Tue, 03 Apr 2007 08:37:58 -0400 Received: (qmail 7903 invoked from network); 3 Apr 2007 12:37:56 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 12:37:56 -0000 Message-ID: <46124A54.3050602@cisco.com> Date: Tue, 03 Apr 2007 08:36:36 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] LISP and the Global Internet Architecture References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <4611A5B6.1020407@cisco.com> <7E51D495-21DB-4213-B8D9-FC08DB117313@cisco.com> <808E8BA2-7435-4E2F-A447-8F05B6C0CD77@cisco.com> In-Reply-To: <808E8BA2-7435-4E2F-A447-8F05B6C0CD77@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Cc: Tony Li , 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 >> This is simply incorrect. Moving the problem from the RIB/FIB to a >> partially populated cache at a much lower access rate does solve the >> problem: the costs for such equipment will be borne directly and >> solely by the people on the data path. > > This is correct and the motivation for LISP. 1. Do we have evidence this cache will actually work? We have lots of experience showing caches don't work in this sort of environment. If we have such evidence, can you point to it? 2. Do we have evidence showing the first x packets being dropped while the cache is populated through a complex ICMP based process? If so, could you point to it? 3. If the LISP cache can "solve" the growing table size, why not just go back to a cache between the RIB and the FIB? Wouldn't this provide the same benefit, without all the tunneling work? Can you explain the difference between simply going back to an on demand filled cache based on the RIB, verses LISP? 4. How does LISP solve the problem of having more packet processing on the switching engines, and the power drain associated with the ever increasing gate counts on line cards? 5. How long will it be before someone asks for a line card that can look into the "inner" LISP header and filter/etc based on that? Or the third, or the fourth? :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEkpUER27sUhU9OQRAuUEAJkBKLz42EvkitEeFUjHAhkO8ERMFACeOp8y cYyfxAXi2ogIQl4oYZ6es5c= =/F/O -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 08:45:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiNx-0003u1-Dt; Tue, 03 Apr 2007 08:45:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiNv-0003tu-Ip for ram@iab.org; Tue, 03 Apr 2007 08:45:15 -0400 Received: from xmail03.myhosting.com ([168.144.250.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYiNu-0006qe-A5 for ram@iab.org; Tue, 03 Apr 2007 08:45:15 -0400 Received: (qmail 31642 invoked from network); 3 Apr 2007 12:45:13 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 12:45:13 -0000 Message-ID: <46124C0A.7040204@cisco.com> Date: Tue, 03 Apr 2007 08:43:54 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> In-Reply-To: <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Cc: Tony Li , "Fleischman, Eric" , 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 >> Aggregate-ability of locators is wholly irrelevant in a push model, >> since the entire database must be distributed anyway. > > But is it one entry per site. It can be only if there are one set of > locators per site. At the cost of having a larger loc/id mapping table. >> Have we converged on only using a pull model for the mapping? > > I don't think so. IMHO, if we're going to do anything, we need a push model for the loc/id mapping. A pull model would likely destroy any path into true mobility. The final result of a pull model would likely be a loc/id mapping system designed for occasional draws of information being overwhelmed with constant draws of information to support mobility--you can already imagine "pre-pull" systems that speculatively cache loc/id mappings to support mobility. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEkwKER27sUhU9OQRArcQAJ4wFqOwpMXeSvKWqyj/5glK3WM/4QCfX1kv x8y+WcoKbJ8l871B19W4gi4= =tJ8A -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 08:49:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiRX-0007i2-OB; Tue, 03 Apr 2007 08:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYiRW-0007ht-Pp for ram@iab.org; Tue, 03 Apr 2007 08:48:58 -0400 Received: from xmail03.myhosting.com ([168.144.250.18]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYiRV-0007WL-HL for ram@iab.org; Tue, 03 Apr 2007 08:48:58 -0400 Received: (qmail 12354 invoked from network); 3 Apr 2007 12:48:57 -0000 Received: from unknown (HELO [192.168.100.205]) (Authenticated-user:_russ@riw.us@[65.190.218.139]) (envelope-sender ) by xmail03.myhosting.com (qmail-ldap-1.03) with SMTP for ; 3 Apr 2007 12:48:57 -0000 Message-ID: <46124CE9.4020802@cisco.com> Date: Tue, 03 Apr 2007 08:47:37 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP References: <200704022152.l32Lq1J08204@merlot.juniper.net> In-Reply-To: X-Enigmail-Version: 0.94.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 >> This would be an good example to illustrate that LISP 1.5 offer >> *no* reduction of the volume of routing information. To the contrary, >> this example would illustrate how LISP 1.5 would result in increasing >> volume of routing information. > > It reduces the unicast FIB. And the number of routers that have to store > the additional routes. If the size of the unicast FIB table is the "real" problem, can we open up the solution space to all possible solutions that can accomplish this? > Furthermore, the EID-prefix space can aggregate better than today's BGP > core since it is not based on topology. I don't see why or how this would be true. It may be somewhat true in the current, hosts nailed to the floor, provider/enterprise model of things for the big I Internet. But for the rest of the world, I'm not certain this is true at all. :-) Russ - -- riw@cisco.com CCIE <>< Grace Alone -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGEkzpER27sUhU9OQRAq6QAJ0brAkqETsQIruGVjl/BSY/e6hLlQCg5e0l rru2SWjoVTMTsp43szg1gAM= =zjKx -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 09:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjTL-0001vT-Ba; Tue, 03 Apr 2007 09:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjPo-00015m-U2 for ram@iab.org; Tue, 03 Apr 2007 09:51:16 -0400 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 1HYjP1-0004qV-Nv for ram@iab.org; Tue, 03 Apr 2007 09:50:33 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33DoGDD012822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 06:50:17 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l33DoGlW020675; Tue, 3 Apr 2007 08:50:16 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l33DoFEk020653; Tue, 3 Apr 2007 08:50:16 -0500 (CDT) 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); Tue, 3 Apr 2007 06:50:15 -0700 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] LISP and the Global Internet Architecture Date: Tue, 3 Apr 2007 06:49:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177487C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1jOFXSRbyjd1WSDWv8WMNe1ncHwAaZunA References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Apr 2007 13:50:15.0376 (UTC) FILETIME=[01F82500:01C775F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Noel,=20 > Which is why it makes sense to have a jack-up solution that=20 > only the ISP's > have to deploy - they are the ones who will benefit, so they=20 > are the ones > who have the incentive to actually do it. And that's also why it makes > sense to have a jack-up solution which is completely=20 > invisible to customers > (including their routers), because deploying it buys them nothing. It surprises me to hear you say this. Pushing the ITR out towards the provider edge and away from the end user would not seem consistent with RFC1955; would it be consistent with RFC1992? And, if you push the ITR out to the provider edge, how would you handle mobility management within the customer network - Mobile IP? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 09:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjSF-0001Yu-OC; Tue, 03 Apr 2007 09:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjSE-0001Xa-1T for ram@iab.org; Tue, 03 Apr 2007 09:53:46 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYjRw-00067c-LW for ram@iab.org; Tue, 03 Apr 2007 09:53:46 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33DrMG1022864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 06:53:22 -0700 (PDT) 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 l33DrMm0009875; Tue, 3 Apr 2007 06:53:22 -0700 (PDT) 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 l33DrIqf009745; Tue, 3 Apr 2007 06:53:22 -0700 (PDT) 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); Tue, 3 Apr 2007 06:53:19 -0700 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] LISP and the Global Internet Architecture Date: Tue, 3 Apr 2007 06:52:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177487D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1lSwQR7E6D+PLQFal/iMjtS3c1AAYbV/w References: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Apr 2007 13:53:19.0300 (UTC) FILETIME=[6F98B840:01C775F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > Or will uSoft's attempt to drive IPv6 deployment by > including it in Vista succeed? I have more or less been viewing the Microsoft solution as a glimmering hope for incremental deployment. And, if that doesn't pan out, will we have missed the ship(worm)? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 09:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjTL-0001vT-Ba; Tue, 03 Apr 2007 09:54:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjPo-00015m-U2 for ram@iab.org; Tue, 03 Apr 2007 09:51:16 -0400 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 1HYjP1-0004qV-Nv for ram@iab.org; Tue, 03 Apr 2007 09:50:33 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33DoGDD012822 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 06:50:17 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l33DoGlW020675; Tue, 3 Apr 2007 08:50:16 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l33DoFEk020653; Tue, 3 Apr 2007 08:50:16 -0500 (CDT) 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); Tue, 3 Apr 2007 06:50:15 -0700 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] LISP and the Global Internet Architecture Date: Tue, 3 Apr 2007 06:49:15 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177487C@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1jOFXSRbyjd1WSDWv8WMNe1ncHwAaZunA References: <20070403010901.73A5B872CE@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Apr 2007 13:50:15.0376 (UTC) FILETIME=[01F82500:01C775F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 Noel,=20 > Which is why it makes sense to have a jack-up solution that=20 > only the ISP's > have to deploy - they are the ones who will benefit, so they=20 > are the ones > who have the incentive to actually do it. And that's also why it makes > sense to have a jack-up solution which is completely=20 > invisible to customers > (including their routers), because deploying it buys them nothing. It surprises me to hear you say this. Pushing the ITR out towards the provider edge and away from the end user would not seem consistent with RFC1955; would it be consistent with RFC1992? And, if you push the ITR out to the provider edge, how would you handle mobility management within the customer network - Mobile IP? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 09:55:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjSF-0001Yu-OC; Tue, 03 Apr 2007 09:53:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjSE-0001Xa-1T for ram@iab.org; Tue, 03 Apr 2007 09:53:46 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYjRw-00067c-LW for ram@iab.org; Tue, 03 Apr 2007 09:53:46 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33DrMG1022864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 06:53:22 -0700 (PDT) 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 l33DrMm0009875; Tue, 3 Apr 2007 06:53:22 -0700 (PDT) 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 l33DrIqf009745; Tue, 3 Apr 2007 06:53:22 -0700 (PDT) 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); Tue, 3 Apr 2007 06:53:19 -0700 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] LISP and the Global Internet Architecture Date: Tue, 3 Apr 2007 06:52:20 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177487D@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1lSwQR7E6D+PLQFal/iMjtS3c1AAYbV/w References: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 03 Apr 2007 13:53:19.0300 (UTC) FILETIME=[6F98B840:01C775F7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 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 > Or will uSoft's attempt to drive IPv6 deployment by > including it in Vista succeed? I have more or less been viewing the Microsoft solution as a glimmering hope for incremental deployment. And, if that doesn't pan out, will we have missed the ship(worm)? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 10:24:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjv4-0006U2-0y; Tue, 03 Apr 2007 10:23:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYjv2-0006Sp-B3 for ram@iab.org; Tue, 03 Apr 2007 10:23:32 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYjuo-00071T-U7 for ram@iab.org; Tue, 03 Apr 2007 10:23:32 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 03 Apr 2007 16:23:19 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l33ENI4I012551; Tue, 3 Apr 2007 16:23:18 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp362.cisco.com [10.61.65.106]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33ENElZ004939; Tue, 3 Apr 2007 14:23:17 GMT Message-ID: <46126351.4040505@cisco.com> Date: Tue, 03 Apr 2007 16:23:13 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Brian E Carpenter Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <4612360C.2090704@zurich.ibm.com> In-Reply-To: <4612360C.2090704@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1189; t=1175610198; x=1176474198; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=09Deploymentof=0A=20LISP] |Sender:=20; bh=+F15+yLP/qUH/GKLIqRES1OheklGz2PwA+UrJkM9c3I=; b=oEAZdsiufEfQbCDAMxm4zRwwmc9rN/IZM5U7AGQjkPNII4XRPQDMkITA3NaUtISJI/kkNZ/z X4GLes9oKzSoocqyDXH907s26s2uDOP3UAXS9zJV3rw3jqPeQWvo16ke; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: Tony Li , "Fleischman, Eric" , 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 Brian, > Nor me. I think we should consider this as a whole separate topic > from the LISP model as such. It seems to me that every solution we've > talked about that is even vaguely in the id/loc split space calls > for an id/loc mapping service, so we should consider it as an > orthogonal matter. The characteristics of various proposals vary widely from no new mapping needed (SHIM6), use of DNS for the mapping (HIP), to LISP (???). In the case of SHIM6 and HIP it is at least possible to query a mapping service either prior to a communication (HIP) or during setup (SHIM6), but the number of participants is meant to scale to the number of hosts using the service. Because LISP does not touch the end host, in the first place you have a lower scaling requirement to the number of provider edge routers (worst case). Furthermore, there is the ability to aggregate PI address space. You cannot aggregate HITs and there is no similar concept for SHIM6. To me that means that the number of entries is *AT MOST* O(PI addresses in the system). And so I believe you need to consider the ID/Loc mapping service for each mechanism individually. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 10:52:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkMP-0005wP-RN; Tue, 03 Apr 2007 10:51:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkMO-0005wE-6N for ram@iab.org; Tue, 03 Apr 2007 10:51:48 -0400 Received: from mtagate6.de.ibm.com ([195.212.29.155]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYkML-0005ld-My for ram@iab.org; Tue, 03 Apr 2007 10:51:48 -0400 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 l33EphgF172164 for ; Tue, 3 Apr 2007 14:51:43 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.3) with ESMTP id l33EphMF2494474 for ; Tue, 3 Apr 2007 16:51:43 +0200 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 l33EpL5u026372 for ; Tue, 3 Apr 2007 16:51:22 +0200 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 l33EpLgg026343; Tue, 3 Apr 2007 16:51:21 +0200 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA353182; Tue, 3 Apr 2007 16:51:20 +0200 Message-ID: <461269E7.5080508@zurich.ibm.com> Date: Tue, 03 Apr 2007 16:51:19 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Eliot Lear Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <4612360C.2090704@zurich.ibm.com> <46126351.4040505@cisco.com> In-Reply-To: <46126351.4040505@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: Tony Li , "Fleischman, Eric" , 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-04-03 16:23, Eliot Lear wrote: > Brian, >> Nor me. I think we should consider this as a whole separate topic >> from the LISP model as such. It seems to me that every solution we've >> talked about that is even vaguely in the id/loc split space calls >> for an id/loc mapping service, so we should consider it as an >> orthogonal matter. > The characteristics of various proposals vary widely from no new mapping > needed (SHIM6), use of DNS for the mapping (HIP), to LISP (???). In the > case of SHIM6 and HIP it is at least possible to query a mapping service > either prior to a communication (HIP) or during setup (SHIM6), but the > number of participants is meant to scale to the number of hosts using > the service. Because LISP does not touch the end host, in the first > place you have a lower scaling requirement to the number of provider > edge routers (worst case). Furthermore, there is the ability to > aggregate PI address space. You cannot aggregate HITs and there is no > similar concept for SHIM6. To me that means that the number of entries > is *AT MOST* O(PI addresses in the system). > > And so I believe you need to consider the ID/Loc mapping service for > each mechanism individually. I need to write something quite long to explain why I think you're wrong. It may take a while. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 10:59:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkSI-0000rM-Vi; Tue, 03 Apr 2007 10:57:55 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkSH-0000iQ-4N for ram@iab.org; Tue, 03 Apr 2007 10:57:53 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYkSF-0004uL-M7 for ram@iab.org; Tue, 03 Apr 2007 10:57:53 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33EvlB9004117 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 07:57:48 -0700 (PDT) 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 l33Evlt1027545; Tue, 3 Apr 2007 07:57:47 -0700 (PDT) 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 l33Evj9m027422; Tue, 3 Apr 2007 07:57:46 -0700 (PDT) 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); Tue, 3 Apr 2007 07:57:44 -0700 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: Thousands of large PI customers [Re: [RAM]Incremental Deploymentof LISP] Date: Tue, 3 Apr 2007 07:57:25 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A10177487F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46126351.4040505@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thousands of large PI customers [Re: [RAM]Incremental Deploymentof LISP] Thread-Index: Acd1+7xLoYj7scEQQDediVwlpVxN6AABC1iQ References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com><4612360C.2090704@zurich.ibm.com> <46126351.4040505@cisco.com> From: "Templin, Fred L" To: "Eliot Lear" , "Brian E Carpenter" X-OriginalArrivalTime: 03 Apr 2007 14:57:44.0987 (UTC) FILETIME=[6FB9BEB0:01C77600] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Tony Li , "Fleischman, Eric" , 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 > Because LISP does not touch the end host, A small point of clarification; since LISP is deployed on routers, it follows that LISP does not touch the end *host*. But, it does not follow that LISP does not touch the end *platform*, where an end platform consists of a router and one or more hosts. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 11:04:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkYM-0005Ge-IU; Tue, 03 Apr 2007 11:04:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkYL-0005GY-3K for ram@iab.org; Tue, 03 Apr 2007 11:04:09 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYkYH-00005I-Bq for ram@iab.org; Tue, 03 Apr 2007 11:04:09 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l33F3anu017781; Tue, 3 Apr 2007 08:03:36 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l33F3aJp017780; Tue, 3 Apr 2007 08:03:36 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 3 Apr 2007 08:03:36 -0700 From: David Meyer To: Brian E Carpenter Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Message-ID: <20070403150336.GB17613@1-4-5.net> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <4612360C.2090704@zurich.ibm.com> Mime-Version: 1.0 In-Reply-To: <4612360C.2090704@zurich.ibm.com> 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: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: Tony Li , "Fleischman, Eric" , 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="===============1450032898==" Errors-To: ram-bounces@iab.org --===============1450032898== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="CUfgB8w4ZwR/yMy5" Content-Disposition: inline --CUfgB8w4ZwR/yMy5 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Apr 03, 2007 at 01:10:04PM +0200, Brian E Carpenter wrote: > On 2007-04-03 06:26, Dino Farinacci wrote: > >>Aggregate-ability of locators is wholly irrelevant in a push model,=20 > >>since the entire database must be distributed anyway. > > > >But is it one entry per site. It can be only if there are one set of=20 > >locators per site. > > > >>Have we converged on only using a pull model for the mapping? > > > >I don't think so. >=20 > Nor me. I think we should consider this as a whole separate topic > from the LISP model as such. It seems to me that every solution we've > talked about that is even vaguely in the id/loc split space calls > for an id/loc mapping service, so we should consider it as an > orthogonal matter. It seems pretty clear that the encap part of the map/encap schemes is relatively easy. As I think you are pointing out, it is the map functionality that is difficult (hard). And in particular, if we move the scaling problem (such as I see it, understanding there is no consensus on that issue; let's not open that here) to the map functionality, then we will have to deal with that problem there, and it is unclear that that is an easier domain in which to do this work. Now, maybe it is, but I haven't seen anything that would lead one (or me in particular) to that conclusion. In fact, I can see it being much harder for a multitude of reasons, many of which will not be technical (cf. infrastructure ENUM). =09 That being said, any map/encap proposal that does not at least specify the required properties of the map scheme will be very weak indeed (since such a proposal will be skirting the hard part of all of this). So while I admire the desire to decouple the map functionality, it seems very little will be gained by doing so, since many of the hard problems will remain unsolved. --dmm --CUfgB8w4ZwR/yMy5 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGEmzIORgD1qCZ2KcRAh9TAJ9yk/lU/Vv0itOoV32yMoeneJms7QCfQixI u3oHoqSlcjlTy2yngVLM6Us= =9XpX -----END PGP SIGNATURE----- --CUfgB8w4ZwR/yMy5-- --===============1450032898== 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 --===============1450032898==-- From ram-bounces@iab.org Tue Apr 03 11:16:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkjD-00068m-6H; Tue, 03 Apr 2007 11:15:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkjB-000679-RY for ram@iab.org; Tue, 03 Apr 2007 11:15:21 -0400 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 1HYkfL-0002RY-M1 for ram@iab.org; Tue, 03 Apr 2007 11:11:51 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33FB6ne004835 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 08:11:07 -0700 (PDT) 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 l33FB5mK026167; Tue, 3 Apr 2007 08:11:05 -0700 (PDT) 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 l33FAsBx025601; Tue, 3 Apr 2007 08:11:05 -0700 (PDT) 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); Tue, 3 Apr 2007 08:11:05 -0700 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: Thousands of large PI customers [Re: [RAM] IncrementalDeploymentof LISP] Date: Tue, 3 Apr 2007 08:10:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774880@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070403150336.GB17613@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Thousands of large PI customers [Re: [RAM] IncrementalDeploymentof LISP] Thread-Index: Acd2AWK7NQYS6SblQeWmaXxtVXbdbgAADi8w References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><4610C965.8010208@zurich.ibm.com><474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com><4611232A.2030006@zurich.ibm.com><34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com><7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com><4612360C.2090704@zurich.ibm.com> <20070403150336.GB17613@1-4-5.net> From: "Templin, Fred L" To: "David Meyer" , "Brian E Carpenter" X-OriginalArrivalTime: 03 Apr 2007 15:11:05.0179 (UTC) FILETIME=[4CAD5AB0:01C77602] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: Tony Li , "Fleischman, Eric" , 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 > That being said, any map/encap proposal that does not at > least specify the required properties of the map scheme > will be very weak indeed (since such a proposal will be > skirting the hard part of all of this). So while I admire > the desire to decouple the map functionality, it seems > very little will be gained by doing so, since many of the > hard problems will remain unsolved. Well said, David. For better or worse, IPvLX (due to be updated based on exchanges on this list) at least takes a stab at what the mapping function might look like. For everyone who thinks they have a better proposal, let's hear 'em... Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 11:18:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkmB-0007Rv-Sd; Tue, 03 Apr 2007 11:18:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYkmA-0007RJ-4s for ram@iab.org; Tue, 03 Apr 2007 11:18:26 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYkm7-0004Gp-PU for ram@iab.org; Tue, 03 Apr 2007 11:18:26 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l33FIG2X018020; Tue, 3 Apr 2007 08:18:16 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l33FIGvv018019; Tue, 3 Apr 2007 08:18:16 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Tue, 3 Apr 2007 08:18:16 -0700 From: David Meyer To: Eliot Lear Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Message-ID: <20070403151816.GA17881@1-4-5.net> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <4612360C.2090704@zurich.ibm.com> <46126351.4040505@cisco.com> Mime-Version: 1.0 In-Reply-To: <46126351.4040505@cisco.com> 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: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: Tony Li , "Fleischman, Eric" , 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="===============0492032465==" Errors-To: ram-bounces@iab.org --===============0492032465== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > the service. Because LISP does not touch the end host, in the first=20 > place you have a lower scaling requirement to the number of provider=20 > edge routers (worst case). =20 Even though LISP is intended to be a "network side" solution, I really don't see any reason that it (ITR or even ETR) couldn't be implemented in a host. > Furthermore, there is the ability to aggregate PI address space. ^^ Is, or is not?=20 =09 > You cannot aggregate HITs and there is no similar concept for > SHIM6. To me that means that the number of entries is *AT > MOST* O(PI addresses in the system).=20 Right, and that's really a large part of the problem (O(number_of(PI prefixes)), in the event you are one of the those who believe there is a scaling problem). > And so I believe you need to consider the ID/Loc mapping service for=20 > each mechanism individually. Considering each separately is a fine idea, but it would truely be a shame if this became another place to proliforate the ways to do thing (in this case X is a mapping service of some sort).=20 --dmm --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGEnA4ORgD1qCZ2KcRAvNxAJ4/5X+/l7/2XzUYZ/i3LhII9iUm6wCfcUWa I4dTwvyYNA6qF2/Bih8fHxE= =5qJu -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3-- --===============0492032465== 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 --===============0492032465==-- From ram-bounces@iab.org Tue Apr 03 11:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYku6-0007hP-AZ; Tue, 03 Apr 2007 11:26:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYku4-0007gY-EU for ram@iab.org; Tue, 03 Apr 2007 11:26:36 -0400 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 1HYkt1-0007Aq-8E for ram@iab.org; Tue, 03 Apr 2007 11:25:33 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33FPUXN017343 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 3 Apr 2007 10:25:30 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l33FPU9Z029273 for ; Tue, 3 Apr 2007 10:25:30 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l33FPKJs028754 for ; Tue, 3 Apr 2007 10:25:29 -0500 (CDT) 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); Tue, 3 Apr 2007 08:25:24 -0700 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: Tue, 3 Apr 2007 08:24:26 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774881@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070403151816.GA17881@1-4-5.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: IPvLX -> IPXXL Thread-Index: Acd2A2G4+u8u9/0cRGyDTmNORTC+LAAAEH+g References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><4610C965.8010208@zurich.ibm.com><474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com><4611232A.2030006@zurich.ibm.com><34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com><7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com><4612360C.2090704@zurich.ibm.com> <46126351.4040505@cisco.com> <20070403151816.GA17881@1-4-5.net> From: "Templin, Fred L" To: X-OriginalArrivalTime: 03 Apr 2007 15:25:25.0080 (UTC) FILETIME=[4D37D580:01C77604] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [RAM] IPvLX -> IPXXL 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 Just to reserve the acronym, I am contemplating a future proposal: "IP with eXtreme eXtension of Links (IPXXL)". It would be very much like IPvLX, only bigger. 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 Tue Apr 03 12:42:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm3L-0005SH-VP; Tue, 03 Apr 2007 12:40:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm3L-0005S3-Ab for ram@iab.org; Tue, 03 Apr 2007 12:40:15 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYm3J-0004RY-QL for ram@iab.org; Tue, 03 Apr 2007 12:40:15 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l33GQ861038397; Tue, 3 Apr 2007 09:26:08 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Apr 2007 09:39:45 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Apr 2007 09:39:45 -0700 In-Reply-To: <46123624.50503@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <46114E69.20901@cisco.com> <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> <46123624.50503@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Date: Tue, 3 Apr 2007 09:39:43 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Cc: ram@iab.org Subject: [RAM] Re: Scaling target 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 Eliot, On Apr 3, 2007, at 4:10 AM, Eliot Lear wrote: > I don't see why we should assume this. Take the common case where > you have a gazillion residential DSL connections. Good example. > Why don't they just continue to use the PA space and let the SPs > handle any LISP. Because multi-homing with PA is hard and annoying. My assumption is that people are going to be more and more dependent on Internet connectivity in the future (not only for data, but also VoIP, TV/movies-over-Internet, home security monitoring, home automation, etc). With dependency comes demand for increased reliability. I believe this demand for reliability will drive increased requirements for multi-homing, particularly in the residential markets and particularly via multiple high speed wireless providers. A locator/ID split solution would allow _anyone_ to be provider independent and to multi-home without having to know BGP. I can easily imagine Internet service becoming commodity in the sense that customers change providers rapidly as costs/load/performance shifts. Try doing that with PA. >> The goal of the mapping is to ensure the RIB/FIB scales with the >> number of service providers, not the number of network attachment >> edge points. > Nice goal. I do not see how we get there. The reason the RIB/FIB currently tends to scale to the number of network attachment points is because having your own PI address space gives you two major advantages (no need to renumber when you change providers and (relatively) easy multi-homing) over PA space. If you provide these advantages via a mechanism that doesn't require folks to know BGP and which makes multi-homing as simple as calling up another provider and saying "I want service from you too", I believe there will be a natural tendency away from everybody wanting PI space. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 12:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm9t-00039K-Fn; Tue, 03 Apr 2007 12:47:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm9s-00037q-62 for ram@iab.org; Tue, 03 Apr 2007 12:47:00 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYm9p-0006jb-Ow for ram@iab.org; Tue, 03 Apr 2007 12:47:00 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l33GXC65038412; Tue, 3 Apr 2007 09:33:16 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Apr 2007 09:46:53 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Apr 2007 09:46:53 -0700 In-Reply-To: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> References: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Tue, 3 Apr 2007 09:46:51 -0700 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Apr 2, 2007, at 7:08 PM, Noel Chiappa wrote: > Which leads me to wonder what the future really is, though. What > happens > when the IPv4 addresses really do start to run out in a few years? > Will we > see a market develop for IPv4 addresses, plus continued use of NAT? Yes. And this will drive increased fragmentation of the routing space, resulting in increased routing information load. > Or will > uSoft's attempt to drive IPv6 deployment by including it in Vista > succeed? Microsoft is a necessary but insufficient condition for IPv6 to gain traction. Since there is no "killer application" for IPv6, what is really needed is: a) removal of distinction to end user (and end user support organizations) about what kind of address is being used b) a cost benefit for ISPs and content providers to add IPv6 capability to their existing IPv4 services It may be that the IPv4 market will contribute to (b). > And even more importantly, is there really any scope left for good > fundamentals-based engineering, or will we always be restricted by > economic/business considerations to the cheapest thing we can > possibly come > up with that more or less kludges the network into continued > operation? It is generally difficult to re-engineer a Sopwith Camel into an F-22 in flight. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 12:47: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 1HYmA3-0003Qq-Ck; Tue, 03 Apr 2007 12:47:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmA1-0003PH-C6 for ram@iab.org; Tue, 03 Apr 2007 12:47:09 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYm9y-0006wq-OA for ram@iab.org; Tue, 03 Apr 2007 12:47:09 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l33GXC69038412; Tue, 3 Apr 2007 09:33:24 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Apr 2007 09:47:01 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Apr 2007 09:47:01 -0700 In-Reply-To: <46124C0A.7040204@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <46124C0A.7040204@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Tue, 3 Apr 2007 09:47:00 -0700 To: Russ White X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Russ, On Apr 3, 2007, at 5:43 AM, Russ White wrote: > IMHO, if we're going to do anything, we need a push model for the > loc/id > mapping. A push model moves the routing information thrash from a relatively small number of very well connected, extremely powerful "core" routers to a very large number of relatively poorly connected (in comparison to the core), relatively weak edge(-ish) routers. This will almost certainly imply changes to the routing system will take much longer to propagate and convergence of the routing system will be a wistful dream. > A pull model would likely destroy any path into true mobility. Actually... Assume you have a node with identifier X moving between service provider with locator "A" and service provider with locator "B". While in the "A" service provider realm, the mapping is X->A. At the A/B boundary, X notifies B of its entrance, changing its mapping to X- >B. However, in a pull model, you'll have a cache and traffic will continue to go to A until the cache entry expires. To address this, X notifies A of the transition, inserting a forwarding mapping (that will last until the cache entries can be assumed to expire) at A to forward X traffic to B. If X moves from B to C, it can either update its forward mapping at A to point to C or it can insert a forward mapping at B that points to C. > The final result of a pull model would likely be a loc/id mapping > system > designed for occasional draws of information being overwhelmed with > constant draws of information to support mobility--you can already > imagine "pre-pull" systems that speculatively cache loc/id mappings to > support mobility. Given caching and forwarding as described above, I'm not sure why you'd think a pull system would be overwhelmed. How would a push model work in the mobility case? Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 12:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm9u-0003Gu-QE; Tue, 03 Apr 2007 12:47:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYm9t-00037x-1M for ram@iab.org; Tue, 03 Apr 2007 12:47:01 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYm9q-0006jf-Kx for ram@iab.org; Tue, 03 Apr 2007 12:47:01 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l33GXC61038412; Tue, 3 Apr 2007 09:33:12 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Apr 2007 09:46:49 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Apr 2007 09:46:49 -0700 In-Reply-To: <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Tue, 3 Apr 2007 09:46:48 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Tony, On Apr 2, 2007, at 1:20 PM, Tony Li wrote: >> I'd agree with "DNS server" and "ITR", however assuming the DNS >> server has to be numbered out of locator space instead of >> identifier space, putting the host on the same physical platform >> means you lose one of the big advantages of ID/LOC separation: the >> ability to transparently "renumber". > at's only an issue if there are other hosts dependent on that "DNS > server" functionality. If one was to co-locate everything, then > you can effectively morph LISP into being a purely host-based > solution. Maybe it's me, but I don't really see a demand for host-based solutions. I see a demand for "site"-based solutions. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 12:56:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmIl-0000oj-VZ; Tue, 03 Apr 2007 12:56:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmIi-0000nn-Tt for ram@iab.org; Tue, 03 Apr 2007 12:56:09 -0400 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 1HYmIf-0002qe-K3 for ram@iab.org; Tue, 03 Apr 2007 12:56:08 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l33Gu4ko023456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 11:56:04 -0500 (CDT) 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 l33Gu3DL007216; Tue, 3 Apr 2007 09:56:03 -0700 (PDT) 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 l33Gtk4r006321; Tue, 3 Apr 2007 09:55:58 -0700 (PDT) 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); Tue, 3 Apr 2007 09:55:52 -0700 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] Incremental Deployment of LISP Date: Tue, 3 Apr 2007 09:55:10 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774882@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Incremental Deployment of LISP Thread-Index: Acd2D79X3dJ5Vp5fT66QOOB0dKvx2wAAHolQ References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com><5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org><68BE7589-C868-49FC-849B-976B61D10434@cisco.com> From: "Templin, Fred L" To: "David Conrad" , "Tony Li" X-OriginalArrivalTime: 03 Apr 2007 16:55:52.0072 (UTC) FILETIME=[EFF51880:01C77610] 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 > Maybe it's me, but I don't really see a demand for host-based =20 > solutions. Not host-based; *platform* based (where, a platform is a router and its attached hosts). A vehicle could be a platform. An airplane could be a platform. *My laptop could be a platform if it acted as both a router and a host.* > I see a demand for "site"-based solutions. A platform is a site unto itself. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 13:13:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmYK-0003Iw-1v; Tue, 03 Apr 2007 13:12:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmYJ-0003In-AS for ram@iab.org; Tue, 03 Apr 2007 13:12:15 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmYH-0007aO-Vu for ram@iab.org; Tue, 03 Apr 2007 13:12:15 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 03 Apr 2007 10:12:13 -0700 X-IronPort-AV: i="4.14,366,1170662400"; d="scan'208"; a="680986885:sNHT52696156" Received: from rcallon-lt1.juniper.net ([172.23.1.243]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l33HC8J90473; Tue, 3 Apr 2007 10:12:09 -0700 (PDT) (envelope-from rcallon@juniper.net) Message-Id: <5.0.0.25.2.20070403124024.03718eb0@zircon.juniper.net> X-Sender: rcallon@zircon.juniper.net X-Mailer: QUALCOMM Windows Eudora Version 5.0 Date: Tue, 03 Apr 2007 13:12:04 -0400 To: Dino Farinacci From: Ross Callon Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] In-Reply-To: <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> References: <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 At 09:26 PM 4/2/2007 -0700, Dino Farinacci wrote: >>Aggregate-ability of locators is wholly irrelevant in a push model, >>since the entire database must be distributed anyway. > >But is it one entry per site. It can be only if there are one set of >locators per site. I understand that for those sites that are multi-homed and are using a PI address, this might be turned into one entry per site in the mapping table. In this case one entry in the routing table turns into one entry in the mapping table (modulo the possibility that there might be more sites that choose to be multi-homed and use a PI address, than there would have been with the current routing and addressing scheme). What about sites that are currently single-homed and use a PA address? Will they need to be listed in the mapping table? Suppose that there is a host Hd in a dual homed site, Sd, that has a packet to send to a host Hs in a single-homed site Ss. A router (called Rd) in the dual-homed site receives the packet with a source address for Hd (which is not globally routable) and a destination address Hs (which is globally routable). I am thinking that we might want to still use encapsulation in this case since the packet would otherwise be going out on the global Internet with a source address that is not routable. Thus Rd might encapsulate the packet in another IP header with its own address (Rd) as the source address, but it needs to know what address to use for the destination address. If it uses the address of the destination host in the encapsulating header, then either the destination host will need to know to decapsulate the extra header, or some router close to the destination will need to know to snoop packets that are not to it, and strip off the extra header. If nothing else this snooping and stripping seems to break other uses of IP-in-IP encapsulation, unless we get a unique value of the protocol field in the IP header reserved for LISP IP-in-IP encapsulation (which should be simple to do if LISP is widely deployed). If on the other hand the encapsulating router uses the address of a router close to the destination (the one that is going to do the decapsulation) as the destination address in the encapsulating header, then the host Hs or its site Ss needs to be in the mapping table, which would make the table much larger than the IP routing table. (if the table is in something that resembles DNS with a pull model then the size doesn't seem to be an issue -- if we use a push model then having each single-homed site in the mapping table would seem to be a significant issue). >>Have we converged on only using a pull model for the mapping? > >I don't think so. > >Dino I think that I agree that I haven't noticed convergence on this point. Ross >_______________________________________________ >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 Apr 03 13:38:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmwd-0005w4-LG; Tue, 03 Apr 2007 13:37:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYmwb-0005vz-Vx for ram@iab.org; Tue, 03 Apr 2007 13:37:21 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYmwa-0005M2-K6 for ram@iab.org; Tue, 03 Apr 2007 13:37:21 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l33HbEhM016021 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 10:37:15 -0700 Received: from [129.46.226.191] (carbuncle.qualcomm.com [129.46.226.191]) by sabrina.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l33HbBE3003933; Tue, 3 Apr 2007 10:37:13 -0700 Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F 3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8 B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-784 3-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> Date: Tue, 3 Apr 2007 10:37:10 -0700 To: David Conrad , Tony Li From: Ted Hardie Subject: Re: [RAM] Incremental Deployment of LISP Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 At 9:46 AM -0700 4/3/07, David Conrad wrote: >Tony, > >On Apr 2, 2007, at 1:20 PM, Tony Li wrote: >>>I'd agree with "DNS server" and "ITR", however assuming the DNS server has to be numbered out of locator space instead of identifier space, putting the host on the same physical platform means you lose one of the big advantages of ID/LOC separation: the ability to transparently "renumber". >>at's only an issue if there are other hosts dependent on that "DNS server" functionality. If one was to co-locate everything, then you can effectively morph LISP into being a purely host-based solution. > >Maybe it's me, but I don't really see a demand for host-based solutions. I see a demand for "site"-based solutions. Then you don't see a demand for real mobility. For an end-node which changes points of attachment frequently, the current system uses a kludge (a tunnel back to a "home" network, so that the node can pretend to be at some putative usual place in the network topology). That forces the node into making local next-hop decisions, as it will always have at least two interfaces (tunnel and local access network) which have very different latency characteristics, are in different parts of the topology, and may have different reachability. Devices which have the capability to attach using multiple different technologies (wired+wireless, multiple radios, plus tunnel interfaces) are also increasingly typical, and if they aren't the majority now, they will be by the time anything this group is discussing deploys. If we can define and get deployment for a system which allows a flow to pass from end-to-end using a stable identifier as a target, even if one or both of the end-nodes is not attached to its putatively usual place in its "home" network, that is a very big win. My concern with many of the jack-up discussions to date is that they appear to aim at interconnecting private address realms at a level that would end up perpetuating the kind of tunneling that is already a problem now. For folks who don't like ICE and friends now, this kind of jack-up is only going to make things worse, as there will be yet another set of opaque middle boxes in the network that the end-nodes will be hard-pressed to discover but cannot ignore. regards, Ted Hardie _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 14:20:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnaP-0002zG-7e; Tue, 03 Apr 2007 14:18:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnaO-0002z9-Hd for ram@iab.org; Tue, 03 Apr 2007 14:18:28 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYnaA-0001zR-Vv for ram@iab.org; Tue, 03 Apr 2007 14:18:28 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id DEEB419869C; Tue, 3 Apr 2007 21:18:13 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9A0BB198681; Tue, 3 Apr 2007 21:18:13 +0300 (EEST) Message-ID: <46129A66.3080509@piuha.net> Date: Tue, 03 Apr 2007 21:18:14 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Re: Scaling target References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <46114E69.20901@cisco.com> <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> <46123624.50503@cisco.com> 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: cf4fa59384e76e63313391b70cd0dd25 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 > If you provide these advantages via a mechanism that doesn't require > folks to know BGP and which makes multi-homing as simple as calling up > another provider and saying "I want service from you too", I believe > there will be a natural tendency away from everybody wanting PI space. Yes. But until the details are worked out its unclear to me what the costs associated with the separation actually are. What other things would an end-site/border router need in the place of current mechanisms? Would they need another protocol for pushing mappings around the globe? Would this be less, more, or equal to the complexity of running BGP? What would the security mechanisms be that an end site would need to show the rest of the world that its identifiers are now at a new location? Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 14:38:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnsS-0001GB-C0; Tue, 03 Apr 2007 14:37:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYnsQ-0001G1-A8 for ram@iab.org; Tue, 03 Apr 2007 14:37:06 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYnsK-0001t1-SP for ram@iab.org; Tue, 03 Apr 2007 14:37:06 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 03 Apr 2007 11:37:00 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l33Ib0fj003050; Tue, 3 Apr 2007 11:37:00 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l33IatEw012097; Tue, 3 Apr 2007 18:37:00 GMT 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, 3 Apr 2007 11:36:54 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 11:36:54 -0700 In-Reply-To: <20070403150336.GB17613@1-4-5.net> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <4612360C.2090704@zurich.ibm.com> <20070403150336.GB17613@1-4-5.net> Mime-Version: 1.0 (Apple Message framework v752.3) X-Gpgmail-State: !signed Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <376784E3-C54D-4AF4-9B59-022D342292B6@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Tue, 3 Apr 2007 11:36:52 -0700 To: David Meyer X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 18:36:54.0588 (UTC) FILETIME=[0D7F9FC0:01C7761F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1619; t=1175625420; x=1176489420; c=relaxed/simple; s=sjdkim1004; 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=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=20Deploymentof=20LISP] |Sender:=20; bh=jwDEbH+WC7IsDtgZZogWT1eUCNuBTSJAalBFt3WW+5w=; b=DJyCBSU2WUIQqTs5c3hbx92vAZnPDr/WuYdDsyLq50S/varNAyLNxWnHHovpSoE0J8Q7NVDN aCEEfBPrtqyOWqbgdtBjBpIvxfFo5ldQQ6EPGgE9KHLuHs2u2jEylDmrbUnn6QbDdPizqRumU+ KmAD16tYoXoZKO1DPI968eLUs=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: "Fleischman, Eric" , 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 >> Nor me. I think we should consider this as a whole separate topic >> from the LISP model as such. It seems to me that every solution we've >> talked about that is even vaguely in the id/loc split space calls >> for an id/loc mapping service, so we should consider it as an >> orthogonal matter. > > That being said, any map/encap proposal that does not at > least specify the required properties of the map scheme > will be very weak indeed (since such a proposal will be > skirting the hard part of all of this). So while I admire > the desire to decouple the map functionality, it seems > very little will be gained by doing so, since many of the > hard problems will remain unsolved. I agree that the mapping mechanism is the keystone in any map-and- encap solution. It seems to me that if we could elevate the discussion to a more conceptual level about how to create scalable mappings that we would accelerate the overall process. I think we do know that there are mapping mechanisms that are not going to scale. We can pretty quickly characterize those by looking at the rate of mapping operations times the size of the state that needs to be stored. This "rate * state" product is key because when you have both high rate and large state, it implies that the implementor cannot reasonably make good space/time tradeoffs. There are obvious ways of attacking the rate * state product. You can decrease the rate by distribution. You can decrease the state by going to a pull model. I suspect that there are other approaches... Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 15:02:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoFb-0001sO-Tf; Tue, 03 Apr 2007 15:01:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoFZ-0001sG-S4 for ram@iab.org; Tue, 03 Apr 2007 15:01:01 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYoFY-0000y1-J4 for ram@iab.org; Tue, 03 Apr 2007 15:01:01 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2007 15:01:01 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l33J0u77008787; Tue, 3 Apr 2007 15:00:56 -0400 Received: from [69.94.204.63] (rtp-vpn2-251.cisco.com [10.82.240.251]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l33J0uGd009127; Tue, 3 Apr 2007 19:00:56 GMT In-Reply-To: <4610F11C.4030005@dial.pipex.com> References: <4610F11C.4030005@dial.pipex.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7948A5D3-1D70-4461-AFBA-9700ADF04362@cisco.com> Content-Transfer-Encoding: 7bit From: David R Oran Subject: Re: [RAM] EATing into the core bandwidth Date: Tue, 3 Apr 2007 15:00:49 -0400 To: Elwyn Davies X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1364; t=1175626856; x=1176490856; c=relaxed/simple; s=rtpdkim1001; 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]=20EATing=20into=20the=20core=20bandwidth |Sender:=20 |To:=20Elwyn=20Davies=20; bh=2pvKCu1rLhvw2hZwNbVPd1gjtKQ3PGRb3QgW1K0ldjY=; b=Te5ch6cmQmfdI/M8p0GehSJuqrTm4piSD+R9BamjPfqnZS5rLLeZsNkEhamho7WuMHJBoLVa LO+ZJxCAeb5CRDZx4/smAvPlL0DP3FV5+fSXBdMPo9A1iFkmubkvLXtR; Authentication-Results: rtp-dkim-1; header.From=oran@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Cc: RAM 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 Apr 2, 2007, at 8:03 AM, Elwyn Davies wrote: > My mind was obviously too into taxes this Monday morning (the end > of the UK tax year soon)... > > Just a reminder when we are adding up the costs and benefits of the > various approaches, such as LISP, that some of them impose EAT > (Encapsulation Added Tax). > > Calculations based on the distribution of packet sizes in the > current network indicate that LISP would impose an extra average > overhead on IPv4 traffic of around 5 to 7% in bits to be carried. > The exact figure depends on the distribution you use but is heavily > biassed by the large number of TCP ACK packets for which EAT is > around 45%. If the same distributions are used for IPv6 traffic > the overhead rises to 7 to 9% assuming a similar sort of LISP header. > > Whilst these are not enormous figures, given the organic growth in > traffic, they are truly overhead that is applicable to all future > traffic and that gains no extra revenue. This might be a > significant factor in an increasingly commoditised backbone network. > If this is a real concern we can always do IPHC on the inner header. Good point to keep in mind though. > /Elwyn > > _______________________________________________ > 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 Apr 03 15:13:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoRA-0001vl-4V; Tue, 03 Apr 2007 15:13:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoR9-0001vg-2D for ram@iab.org; Tue, 03 Apr 2007 15:12:59 -0400 Received: from audl953.usa.alcatel.com ([143.209.238.162]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYoR7-0003ag-OE for ram@iab.org; Tue, 03 Apr 2007 15:12:59 -0400 Received: from usdalsbhs02.ad3.ad.alcatel.com (usdalsbhs02.usa.alcatel.com [172.22.216.13]) by audl953.usa.alcatel.com (ALCANET) with ESMTP id l33JCkrQ013611; Tue, 3 Apr 2007 14:12:46 -0500 Received: from [128.251.17.20] ([172.22.216.4]) by usdalsbhs02.ad3.ad.alcatel.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.2499); Tue, 3 Apr 2007 14:12:45 -0500 In-Reply-To: <7948A5D3-1D70-4461-AFBA-9700ADF04362@cisco.com> References: <4610F11C.4030005@dial.pipex.com> <7948A5D3-1D70-4461-AFBA-9700ADF04362@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <1F65294C-041F-4010-98B3-3D17CBCB2811@alcatel.com> Content-Transfer-Encoding: 7bit From: Andrew Lange Subject: Re: [RAM] EATing into the core bandwidth Date: Tue, 3 Apr 2007 12:12:40 -0700 To: David R Oran X-Mailer: Apple Mail (2.752.2) X-OriginalArrivalTime: 03 Apr 2007 19:12:46.0008 (UTC) FILETIME=[0FD84380:01C77624] X-Scanned-By: MIMEDefang 2.51 on 143.209.238.34 X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: RAM 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 Apr 3, 2007, at 12:00 PM, David R Oran wrote: > > On Apr 2, 2007, at 8:03 AM, Elwyn Davies wrote: > >> My mind was obviously too into taxes this Monday morning (the end >> of the UK tax year soon)... >> >> Just a reminder when we are adding up the costs and benefits of >> the various approaches, such as LISP, that some of them impose EAT >> (Encapsulation Added Tax). >> >> Calculations based on the distribution of packet sizes in the >> current network indicate that LISP would impose an extra average >> overhead on IPv4 traffic of around 5 to 7% in bits to be carried. >> The exact figure depends on the distribution you use but is >> heavily biassed by the large number of TCP ACK packets for which >> EAT is around 45%. If the same distributions are used for IPv6 >> traffic the overhead rises to 7 to 9% assuming a similar sort of >> LISP header. >> >> Whilst these are not enormous figures, given the organic growth in >> traffic, they are truly overhead that is applicable to all future >> traffic and that gains no extra revenue. This might be a >> significant factor in an increasingly commoditised backbone network. >> > If this is a real concern we can always do IPHC on the inner > header. Good point to keep in mind though. I'm assuming this is RFC 2507-style header compression. Header compression is computationally expensive, and, from my understanding, difficult to do at high speeds. I do not know of any 10 Gbps header compression hardware. This would also add not insignificant cost. Andrew >> /Elwyn >> >> _______________________________________________ >> 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 Tue Apr 03 15:17:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoUp-00037b-7P; Tue, 03 Apr 2007 15:16:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYoUo-00036c-12 for ram@iab.org; Tue, 03 Apr 2007 15:16:46 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYoUm-00049o-L0 for ram@iab.org; Tue, 03 Apr 2007 15:16:46 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 2EEF319869C; Tue, 3 Apr 2007 22:16:44 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E18ED198689; Tue, 3 Apr 2007 22:16:43 +0300 (EEST) Message-ID: <4612A81C.20405@piuha.net> Date: Tue, 03 Apr 2007 22:16:44 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Peter Schoenmaker Subject: TE requirements (was: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP)) References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <08FEEA3E-FE05-4076-81F5-F539653F62A9@lugs.com> In-Reply-To: <08FEEA3E-FE05-4076-81F5-F539653F62A9@lugs.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: cf4fa59384e76e63313391b70cd0dd25 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 Peter, > For the case of multihomed end sites the weighting in the mapping > lookup should be sufficient for TE. The requirements are fairly > simple. For the case of TE between ISPs, the TE requirements are more > complicated. Hot potato vs cold potato. Which adjacent AS to prefer, > and which link to an adjacent as to use. Let me ask for a clarification. When you say that the TE requirements are simple for end sites, are you saying that from the point of view of a provider who needs to apply TE to that site? Or from the point of view of the end-site network manager? What about the mapping weights -- is a static mapping sufficient, or does it have to be dynamic? Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 16:10:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpKC-0002Ed-5l; Tue, 03 Apr 2007 16:09:52 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpKB-0002ES-76 for ram@iab.org; Tue, 03 Apr 2007 16:09:51 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYpK7-0002ao-LC for ram@iab.org; Tue, 03 Apr 2007 16:09:51 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 03 Apr 2007 16:09:46 -0400 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l33K9js2001651; Tue, 3 Apr 2007 16:09:45 -0400 Received: from [69.94.204.63] (rtp-vpn2-251.cisco.com [10.82.240.251]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l33K9ilG006713; Tue, 3 Apr 2007 20:09:45 GMT In-Reply-To: <1F65294C-041F-4010-98B3-3D17CBCB2811@alcatel.com> References: <4610F11C.4030005@dial.pipex.com> <7948A5D3-1D70-4461-AFBA-9700ADF04362@cisco.com> <1F65294C-041F-4010-98B3-3D17CBCB2811@alcatel.com> 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: David R Oran Subject: Re: [RAM] EATing into the core bandwidth Date: Tue, 3 Apr 2007 16:09:36 -0400 To: Andrew Lange X-Mailer: Apple Mail (2.752.2) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2409; t=1175630985; x=1176494985; c=relaxed/simple; s=rtpdkim2001; 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]=20EATing=20into=20the=20core=20bandwidth |Sender:=20 |To:=20Andrew=20Lange=20; bh=5WoyEp19SQyn8XXQuGgMVD/mjbsdlHpr0IE0qQcfrz8=; b=TVJqbWjFomO/ySwp+zhIKMgSCSDEqIHz62ZbepL9jAb9JVvAKf/PaXcBBBHGpRvjD5zTDJsB NAH4GY4v34MGmqTA4vPX4KzDlWc8+nxU4GU9DyVnxioGuMdlN88cqw4y; Authentication-Results: rtp-dkim-2; header.From=oran@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: RAM 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 Apr 3, 2007, at 3:12 PM, Andrew Lange wrote: > > On Apr 3, 2007, at 12:00 PM, David R Oran wrote: > >> >> On Apr 2, 2007, at 8:03 AM, Elwyn Davies wrote: >> >>> My mind was obviously too into taxes this Monday morning (the end >>> of the UK tax year soon)... >>> >>> Just a reminder when we are adding up the costs and benefits of >>> the various approaches, such as LISP, that some of them impose >>> EAT (Encapsulation Added Tax). >>> >>> Calculations based on the distribution of packet sizes in the >>> current network indicate that LISP would impose an extra average >>> overhead on IPv4 traffic of around 5 to 7% in bits to be >>> carried. The exact figure depends on the distribution you use >>> but is heavily biassed by the large number of TCP ACK packets for >>> which EAT is around 45%. If the same distributions are used for >>> IPv6 traffic the overhead rises to 7 to 9% assuming a similar >>> sort of LISP header. >>> >>> Whilst these are not enormous figures, given the organic growth >>> in traffic, they are truly overhead that is applicable to all >>> future traffic and that gains no extra revenue. This might be a >>> significant factor in an increasingly commoditised backbone network. >>> >> If this is a real concern we can always do IPHC on the inner >> header. Good point to keep in mind though. > > > I'm assuming this is RFC 2507-style header compression. > > Header compression is computationally expensive, and, from my > understanding, difficult to do at high speeds. I do not know of > any 10 Gbps header compression hardware. This would also add not > insignificant cost. > It's not that expensive if you don't do the second-order deltas. Note too that you'd likely do this at CE/PE boundaries, which for small business is likely to be in the DSL-speed range, and for anything other than big enterprises, unlikely to exceed 100Mbps. Since packet expansion is a concern mostly at the edge, the only place I'd recommend it is at the edge where the speeds are modest. > Andrew > >>> /Elwyn >>> >>> _______________________________________________ >>> 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 Tue Apr 03 16:27:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpab-0001Aa-4b; Tue, 03 Apr 2007 16:26:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYpaa-0001AU-Ex for ram@iab.org; Tue, 03 Apr 2007 16:26:48 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYpaW-00039n-TD for ram@iab.org; Tue, 03 Apr 2007 16:26:48 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l33KCe61038756; Tue, 3 Apr 2007 13:12:41 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Apr 2007 13:26:18 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Apr 2007 13:26:18 -0700 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F 3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8 B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-784 3-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <9411D2C4-FCA1-4DC3-BE0A-3E9AD151FAD8@virtualized.org> From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Tue, 3 Apr 2007 13:26:16 -0700 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Tony Li , 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 Ted, On Apr 3, 2007, at 10:37 AM, Ted Hardie wrote: >> Maybe it's me, but I don't really see a demand for host-based >> solutions. I see a demand for "site"-based solutions. > Then you don't see a demand for real mobility. Sure I do. "Sites" can be mobile (e.g., an airplane, a soldier, a laptop). I haven't wanted to go into detail discussing mobility aspects because (in my experience) (a) people get distracted and (b) MobileIP fans get unhappy. > My concern with many of the jack-up discussions to > date is that they appear to aim at interconnecting private address > realms > at a level that would end up perpetuating the kind of tunneling > that is already > a problem now. So, it is difficult to have your cake and eat it too. If folks are going to insist that applications need to use network topology, they have to be exposed to that topology. One solution to the problem ICE is trying to solve is to configure the node with the locator addresses obtained from the ISP(s). You gain control over the use of network topology but lose the ability to painlessly change ISPs and simple multi-homing. How important is the sort of hackery ICE is attempting to address? Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 17:04:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYq9F-0006yQ-WA; Tue, 03 Apr 2007 17:02:37 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYq9E-0006xl-7p for ram@iab.org; Tue, 03 Apr 2007 17:02:36 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYq9B-0000sw-Pw for ram@iab.org; Tue, 03 Apr 2007 17:02:36 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 03 Apr 2007 14:02:34 -0700 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 l33L2W2r006851; Tue, 3 Apr 2007 14:02:32 -0700 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 l33L2Wwn022556; Tue, 3 Apr 2007 21:02:32 GMT 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, 3 Apr 2007 14:02:32 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 14:02:31 -0700 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.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: Tony Li Subject: Re: [RAM] Incremental Deployment of LISP Date: Tue, 3 Apr 2007 14:02:30 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 21:02:31.0871 (UTC) FILETIME=[655334F0:01C77633] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=379; t=1175634152; x=1176498152; c=relaxed/simple; s=sjdkim8002; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=17awKhMHtd6G3hOp/7t7oeczLpd0STk2IZNrpZTCBPg=; b=nxTFHqF6pxx1Cgm4VfnvXzFkacPoG/FNEABnTeiJXCk+g0b29ueFuAzBUzBfJtWaGIBtWRqC p0GH0GqKOO44nWzecSJ2uJivgPZ/3bmvYIFMIVVC9uaCggd6xVBm/RRh; Authentication-Results: sj-dkim-8; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); 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 > Maybe it's me, but I don't really see a demand for host-based > solutions. I see a demand for "site"-based solutions. Interesting. I've only seen a rejection of host-by-host managed solutions. I haven't seen anything that required a site based solution. It seems to me that some site-managed host based solution is NOT out of the question. Data? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 17:14: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 1HYqKB-0004rK-G3; Tue, 03 Apr 2007 17:13:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqK9-0004r5-JO for ram@iab.org; Tue, 03 Apr 2007 17:13:53 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYqEG-0006rR-HB for ram@iab.org; Tue, 03 Apr 2007 17:08:04 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 03 Apr 2007 14:07:40 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l33L7d8Q012608; Tue, 3 Apr 2007 14:07:39 -0700 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 l33L7TMf013896; Tue, 3 Apr 2007 21:07:39 GMT 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, 3 Apr 2007 14:07:39 -0700 Received: from [171.71.55.191] ([171.71.55.191]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 3 Apr 2007 14:07:38 -0700 In-Reply-To: References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <46124C0A.7040204@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <2558523F-3024-4BB2-B374-0801DEE87CFC@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Tue, 3 Apr 2007 14:07:37 -0700 To: David Conrad X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 03 Apr 2007 21:07:38.0978 (UTC) FILETIME=[1C600420:01C77634] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=228; t=1175634459; x=1176498459; 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:=20Re=3A=20Thousands=20of=20large=20PI=20customers=20[Re=3A=20[R AM]=20Incremental=09Deploymentof=20LISP] |Sender:=20; bh=KWcCmG9IjC/3cYLOa5cYdhE5mWzLI1KV0Hwrb5NMz6I=; b=bDgI4eD9Uu8Su81UE7TJzb38sdDjA+R2hmRtcxPiersfMItuzRLQsoKQ1/Gaf9KFpjcaQrgG U5eJJocm90ABAB9XBlI2LK1JxLDtgLhbH2r6VGKsP8RqgxWTvO7d8eJs; 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: 30ac594df0e66ffa5a93eb4c48bcb014 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 > A push model moves the routing information thrash Let's be very careful here. We were talking about using the push model for the id->locator mapping. That's no more part of 'routing' than DNS is today. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 17:17:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqNE-0005rh-2y; Tue, 03 Apr 2007 17:17:04 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYqND-0005rY-4k for ram@iab.org; Tue, 03 Apr 2007 17:17:03 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HYqNA-0002on-IZ for ram@iab.org; Tue, 03 Apr 2007 17:17:03 -0400 Received: from totoro.qualcomm.com (totoro.qualcomm.com [129.46.61.158]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l33LGu6B013185 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 14:16:56 -0700 Received: from [129.46.226.191] (carbuncle.qualcomm.com [129.46.226.191]) by totoro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l33LGrQB026797; Tue, 3 Apr 2007 14:16:54 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <9411D2C4-FCA1-4DC3-BE0A-3E9AD151FAD8@virtualized.org> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F 3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8 B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-784 3-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> <9411D2C4-FCA1-4DC3-BE0A-3E9AD151FAD8@virtualized.org> Date: Tue, 3 Apr 2007 14:16:52 -0700 To: David Conrad From: Ted Hardie Subject: Re: [RAM] Incremental Deployment of LISP Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Tony Li , 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 At 1:26 PM -0700 4/3/07, David Conrad wrote: > >>My concern with many of the jack-up discussions to >>date is that they appear to aim at interconnecting private address realms >>at a level that would end up perpetuating the kind of tunneling that is already >>a problem now. > >So, it is difficult to have your cake and eat it too. > >If folks are going to insist that applications need to use network topology, they have to be exposed to that topology. Absolutely, and the mic time I've used whining should probably have been better focused on just that point: nodes actually make decisions now by inference or heuristics that would be made better and more easily with actually information on the topology. If we give them that information, things will get better. Obviously, that goal has different scaling characteristics and requires more work than some of the ones asserted on this list. >One solution to the problem ICE is trying to solve is to configure the node with the locator addresses obtained from the ISP(s). That doesn't work now, because most of the time the node is behind a NAT that is sharing a single global locator among multiple nodes. With v6 address pools it is possible, as the node could be assigned a global locator assigned from the ISP. Indeed, that does happen in some environments now; those addresses are used for the media path once they have been identified by the node. In either case, there are two things that frustrate this being fully effective. The first is that in many deployments there are still at least two addresses to choose between, as the locally assigned address used for media is not the address used for communication to the SIP proxy. That address is a tunnel interface back to the "home" network. What application layer mobility SIP has derives from the consistent proxy address for signalling being available when the locally assigned IP addresses (for media) change. The second is the point I made in a previous post--that NATs or firewalls do not allow packets through to target end hosts until the flow has been enabled by action by the target (the "connectivity check" in ICE being the hook for that). If we don't deal with that somehow, having globally reachable addresses doesn't result in true local reachability no matter what. >You gain control over the use of network topology but lose the ability to painlessly change ISPs and simple multi-homing. If I can associate an identifier with multiple points of attachment (either simultaneously or serially at short timescales) that could improve. But we have to recognize that some of the existing mechanisms for application layer mobility/agility will have to change and provide for them. If we don't, we'll either have breakage or yet another failure to launch. >How important is the sort of hackery ICE is attempting to address? Assuming you mean the end result, rather than the specific mechanism, as important as VoIP. regards, Ted >Rgds, >-drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 20:01:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYstw-0000X7-NZ; Tue, 03 Apr 2007 19:59:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYstv-0000Wq-Ng for ram@iab.org; Tue, 03 Apr 2007 19:58:59 -0400 Received: from [2001:4930::204:23ff:feaf:76a8] (helo=smtp1.NoDak.edu) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYsts-0002v0-Bz for ram@iab.org; Tue, 03 Apr 2007 19:58:59 -0400 Received: from [134.129.95.120] (netmender.cc.ndsu.NoDak.edu [134.129.95.120]) (authenticated bits=0) by smtp1.NoDak.edu (8.13.1/8.13.1) with ESMTP id l33NwmH0024229 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 3 Apr 2007 18:58:49 -0500 Mime-Version: 1.0 (Apple Message framework v752.2) In-Reply-To: <2558523F-3024-4BB2-B374-0801DEE87CFC@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <46124C0A.7040204@cisco.com> <2558523F-3024-4BB2-B374-0801DEE87CFC@cisco.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Bruce Curtis Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Tue, 3 Apr 2007 18:58:47 -0500 To: ram@iab.org X-Mailer: Apple Mail (2.752.2) X-Spam-Score: -2.8 (--) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Apr 3, 2007, at 4:07 PM, Tony Li wrote: > >> A push model moves the routing information thrash > > > Let's be very careful here. We were talking about using the push > model for the id->locator mapping. That's no more part of > 'routing' than DNS is today. > > Tony If I'm following correctly don't LISP and other similar solutions move the path up/down information out of the core "routing" information and closer to the edge and place it into the "id- >locator" mapping? So the "information thrash" about paths being up/down is moved whether the model is push or pull? --- Bruce Curtis bruce.curtis@ndsu.edu Certified NetAnalyst II 701-231-8527 North Dakota State University _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 21:20:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYu9W-00074H-KM; Tue, 03 Apr 2007 21:19:10 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYu9V-00074B-6b for ram@iab.org; Tue, 03 Apr 2007 21:19:09 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYu9T-0005GO-Gx for ram@iab.org; Tue, 03 Apr 2007 21:19:09 -0400 Received: from terminus.cust.hotspot.t-mobile.com (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l3415161039200; Tue, 3 Apr 2007 18:05:11 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.cust.hotspot.t-mobile.com (PGP Universal service); Tue, 03 Apr 2007 18:18:48 -0700 X-PGP-Universal: processed; by terminus.cust.hotspot.t-mobile.com on Tue, 03 Apr 2007 18:18:48 -0700 In-Reply-To: <46129A66.3080509@piuha.net> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <46114E69.20901@cisco.com> <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> <46123624.50503@cisco.com> <46129A66.3080509@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Re: Scaling target Date: Tue, 3 Apr 2007 18:18:37 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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, On Apr 3, 2007, at 11:18 AM, Jari Arkko wrote: >> If you provide these advantages via a mechanism that doesn't require >> folks to know BGP and which makes multi-homing as simple as >> calling up >> another provider and saying "I want service from you too", I believe >> there will be a natural tendency away from everybody wanting PI >> space. > Yes. But until the details are worked out its unclear to me what the > costs associated with the separation actually are. What are the costs associated with not doing the separation? There are at least some who say "too high". > What other things would an end-site/border router need in the place > of current mechanisms? First cut: - a way of (securely) creating the identifier/locator mapping - a way of (securely) modifying the identifier/locator mapping - a way of doing a lookup in and/or obtaining the identifier/locator mapping - a way of determining reachability and next hop for the destination locator(s) - in the case of multi-homed sites, a way of determining which of a set of destination locators is "best" - a way of (securely?) determining destination locator failure - a way of coping with "legacy" addresses (this is the hardest part) > Would they need another protocol for pushing mappings around the > globe? Obviously there needs to be some way of obtaining the mapping. If a push model is used, a new protocol (or modification to an existing protocol like BGP) will almost certainly be necessary. If a pull model is used, DNS might be an option. If DNS is not used, a new protocol will almost certainly be necessary. > Would this be less, more, or equal to the complexity of running BGP? That would likely depend on the protocol, I suppose. If the DNS is used, I'd argue it would be less complex. > What would the security mechanisms be that an end site would need > to show the rest of the world that its > identifiers are now at a new location? That would likely depend on the protocol, I suppose. If the DNS is used, DNSSEC can be used to ensure the mapping data published by the identifier prefix zone manager hasn't been modified. The mechanism used to modify the identifier prefix zone could be anything from ssh'ing into the DNS server and using emacs/vi to modify the zone to a nice GUI SSL encrypted web interface. Not rocket science. Of course, this is just one aspect of "security" and I suppose the various other aspects would need to be explored to determine if they need to be addressed. However, as I said in Amsterdam, "There Ain't No Such Thing As A Free Lunch". There will be costs to _any_ approach taken. It isn't sufficient to determine the costs of a single approach as any cost must be judged relative to the costs of other approaches. Outside of some form of LOC/ID separation and PI to Everyone, what other approaches are being actively explored? Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 21:24:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuEf-0003nu-Tt; Tue, 03 Apr 2007 21:24:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuEf-0003np-6J for ram@iab.org; Tue, 03 Apr 2007 21:24:29 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuEd-0006Xv-Ow for ram@iab.org; Tue, 03 Apr 2007 21:24:29 -0400 Received: from terminus.cust.hotspot.t-mobile.com (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l341Ad61039213; Tue, 3 Apr 2007 18:10:40 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.cust.hotspot.t-mobile.com (PGP Universal service); Tue, 03 Apr 2007 18:24:17 -0700 X-PGP-Universal: processed; by terminus.cust.hotspot.t-mobile.com on Tue, 03 Apr 2007 18:24:17 -0700 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Tue, 3 Apr 2007 18:24:14 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Tony, On Apr 3, 2007, at 2:02 PM, Tony Li wrote: >> Maybe it's me, but I don't really see a demand for host-based >> solutions. I see a demand for "site"-based solutions. > Interesting. I've only seen a rejection of host-by-host managed > solutions. I haven't seen anything that required a site based > solution. It seems to me that some site-managed host based > solution is NOT out of the question. Data? I was speaking only of my experience. In the various discussions I've had, I've only had a few folks indicate they thought a host- based solution (that is, a solution that requires host-level configuration) was the right way to go. I suppose a site-managed host based solution would be workable, albeit I personally would be concerned about the additional complexity (management and/or software) this would imply. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 21:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuTd-000605-NL; Tue, 03 Apr 2007 21:39:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuTc-0005zd-9j for ram@iab.org; Tue, 03 Apr 2007 21:39:56 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuTa-0003JJ-Lo for ram@iab.org; Tue, 03 Apr 2007 21:39:56 -0400 Received: from terminus.cust.hotspot.t-mobile.com (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l341QA61039242; Tue, 3 Apr 2007 18:26:11 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.cust.hotspot.t-mobile.com (PGP Universal service); Tue, 03 Apr 2007 18:39:48 -0700 X-PGP-Universal: processed; by terminus.cust.hotspot.t-mobile.com on Tue, 03 Apr 2007 18:39:48 -0700 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F 3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8 B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-784 3-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> <9411D2C4-FCA1-4DC3-BE0A-3E9AD151FAD8@virtualized.org> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: From: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP Date: Tue, 3 Apr 2007 18:39:46 -0700 To: Ted Hardie X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a 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 Ted, On Apr 3, 2007, at 2:16 PM, Ted Hardie wrote: >> If folks are going to insist that applications need to use network >> topology, they have to be exposed to that topology. > Absolutely, and the mic time I've used whining should probably have > been > better focused on just that point: nodes actually make decisions > now by > inference or heuristics that would be made better and more easily with > actually information on the topology. Right. I guess one of my questions is why folks feel it necessary to jump through the various inference and/or heuristic hoops in order to determine topology. Can it be assumed these reasons might go away in the future? Probably not, I know... > In either case, there are two things that frustrate this being > fully effective. > The first is that in many deployments there are still at least two > addresses > to choose between, as the locally assigned address used for media > is not > the address used for communication to the SIP proxy. I'm not sure I fully understand. Wouldn't the application be configured to provide the appropriate referral address for topologically sensitive transport? Or are you saying the routing/ addressing architecture should do this for those applications that care? > The second is the > point I made in a previous post--that NATs or firewalls do not > allow packets > through to target end hosts until the flow has been enabled by > action by the > target (the "connectivity check" in ICE being the hook for that). > If we don't > deal with that somehow, having globally reachable addresses doesn't > result in true local reachability no matter what. I think it would be a mistake to try to come up with an network routing/addressing architecture that attempts to defeat administratively defined policy. This is called an "arms race" and we'll lose. >> How important is the sort of hackery ICE is attempting to address? > Assuming you mean the end result, rather than the specific mechanism, > as important as VoIP. No, I meant the reason folks go and write protocols that making dealing with NAT hard are doing so for some set of reasons. Are those reasons permanent? How much of the hackery due to the desire to bypass administratively defined policy (e.g., tunnel everything through HTTP because nobody blocks HTTP)? Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 03 22:03:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuor-0001Z3-E5; Tue, 03 Apr 2007 22:01:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYuoq-0001Yw-HL for ram@iab.org; Tue, 03 Apr 2007 22:01:52 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYuoo-00026s-Sn for ram@iab.org; Tue, 03 Apr 2007 22:01:52 -0400 Received: from terminus.cust.hotspot.t-mobile.com (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l341lr61039278; Tue, 3 Apr 2007 18:48:01 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.cust.hotspot.t-mobile.com (PGP Universal service); Tue, 03 Apr 2007 19:01:39 -0700 X-PGP-Universal: processed; by terminus.cust.hotspot.t-mobile.com on Tue, 03 Apr 2007 19:01:39 -0700 In-Reply-To: <4611BC16.7090904@firstpr.com.au> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> From: David Conrad Date: Tue, 3 Apr 2007 19:01:29 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Cc: ram@iab.org Subject: [RAM] Re: LISP etc. is not the only path to scalable routing 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 Robin, I haven't had time to read your draft and I am not qualified to comment on hardware architecture, but... On Apr 2, 2007, at 7:29 PM, Robin Whittle wrote: > I am concerned that people in this field have spent so long - a > decade or more - assuming that route aggregation must always be > maximised, that they will find it hard to imagine all the benefits > of tens or hundreds of thousands of AS end-users and ISPs being able > to advertise PI addresses. The benefits to flat routing are obvious. The concern is that at some point flat routing won't scale. Where that point is is open to debate. What you are proposing is to move that point much higher based on new technology (or perhaps new advances that make old technology more cost effective). There is still a point (as you acknowledge) where flat routing breaks down. Whether it is far enough in the future to not matter is one question. > This is not a case of "using more thrust". Sure it is. By analogy, folks are noticing propeller-based technology can't break the sound barrier and you're proposing this new "jet-based" technology. It might work or it might rip the wings off the airplane. > *if* BGP and the router's CPUs can handle the required communications. That's part of the problem. People often say the problem is that the "global routing table is too big". This is poor terminology for many reasons, but mostly because the problem isn't the _size_ of the table, but rather the flux and propagation of routing information in conjunction with the need to lookup bits of that information really really quickly. Your proposal (if I understand it) addresses the latter bit. There is still the former bit. > My understanding of instability in BGP is > that it only affects the prefixes which are being changed. I believe this depends on the type of instability, but there are others on this list who can explore this in much more detail than I. > One problem with assigning PI space to many more smaller AS > end-users is that many more smaller prefixes will probably be poorly > managed. Right. One advantage of a loc/id separation with mapping approach is that it permits end "sites" (for some value of the variable "site") to play in the multi-homing pond without having to also play with BGP. As you note, the folks most likely to screw up BGP are also most likely the folks who would have the long prefixes being inserted into the routing system. BGP is sort of the soft underbelly of the Internet... Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 00:26: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 1HYx3A-0003jW-05; Wed, 04 Apr 2007 00:24:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYx39-0003jR-HG for ram@iab.org; Wed, 04 Apr 2007 00:24:47 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYx38-0006oH-47 for ram@iab.org; Wed, 04 Apr 2007 00:24:47 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l344Aj61039465; Tue, 3 Apr 2007 21:10:49 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Tue, 03 Apr 2007 21:24:26 -0700 X-PGP-Universal: processed; by terminus.local on Tue, 03 Apr 2007 21:24:26 -0700 In-Reply-To: <2558523F-3024-4BB2-B374-0801DEE87CFC@cisco.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <46124C0A.7040204@cisco.com> <2558523F-3024-4BB2-B374-0801DEE87CFC@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <819707F8-4311-41EB-868C-1922D385A377@virtualized.org> From: David Conrad Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] Date: Tue, 3 Apr 2007 21:24:20 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) 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 Tony, On Apr 3, 2007, at 2:07 PM, Tony Li wrote: >> A push model moves the routing information thrash > Let's be very careful here. We were talking about using the push > model for the id->locator mapping. That's no more part of > 'routing' than DNS is today. OK. Poor use of terminology. Today, we have only "routing thrash" where reachability information as defined by prefixes announced by BGP bounces around. In a loc/id model, we still have routing thrash but we'd be introducing a new type of thrash, call it "mapping thrash" which would be addition/changes/deletions of identifier to locator(s) mapping information. For end to end connectivity, you have to contend with both thrashings. In both pull and push, routing thrash is obviously the same. However, in a pull model, since mappings are fetched on demand, mapping thrash is minimized as only active "connections" are fetched. If you're not talking to a site, you don't care that its mapping has changed. In a push model, any change to any mapping needs to be pushed out to all mapping points, regardless of whether you need that information or not. Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 00:47:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxOF-0004Bx-Hg; Wed, 04 Apr 2007 00:46:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxOE-0004Br-3v for ram@iab.org; Wed, 04 Apr 2007 00:46:34 -0400 Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYxOB-0004Kq-M3 for ram@iab.org; Wed, 04 Apr 2007 00:46:34 -0400 Received: from hamtaro.qualcomm.com (hamtaro.qualcomm.com [129.46.61.157]) by ithilien.qualcomm.com (8.13.6/8.12.5/1.0) with ESMTP id l344kR4A022467 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 3 Apr 2007 21:46:28 -0700 Received: from [24.5.145.185] (vpn-10-50-0-63.qualcomm.com [10.50.0.63]) by hamtaro.qualcomm.com (8.13.6/8.13.6/1.0) with ESMTP id l344kO5j007950; Tue, 3 Apr 2007 21:46:26 -0700 (PDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F 3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8 B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-784 3-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> <9411D2C4-FCA1-4DC3-BE0A-3E9AD151FAD8@virtualized.org> Date: Tue, 3 Apr 2007 21:46:23 -0700 To: David Conrad From: Ted Hardie Subject: Re: [RAM] Incremental Deployment of LISP Content-Type: text/plain; charset="us-ascii" X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 At 6:39 PM -0700 4/3/07, David Conrad wrote: >Right. I guess one of my questions is why folks feel it necessary to jump through the various inference and/or heuristic hoops in order to determine topology. Can it be assumed these reasons might go away in the future? > >Probably not, I know... Probably not. Certainly passing media packets through a proxy in a "home" network results in significantly degraded performance compared to passing them directly, so the tunnel interface vs. locally assigned IP interface is likely to be significant as long as Mobile IP in its current form is with us. If you're dealing with a host that is attached in multiple ways (wireline and 802.11 in laptops, for example), it may get less important if the capabilities of the two links are perceived as commonly the same. That's not the case now, and I'm not sure that it will be the case even if the link speeds are equal, as there are situations where the actual topology is different with different attachment types. Unless the end-node gets this information somehow from the routing system, it has to infer it to know whether a specific attachment is useful for reaching a particular peer/server/multicast group. >>In either case, there are two things that frustrate this being fully effective. >>The first is that in many deployments there are still at least two addresses >>to choose between, as the locally assigned address used for media is not >>the address used for communication to the SIP proxy. > >I'm not sure I fully understand. Wouldn't the application be configured to provide the appropriate referral address for topologically sensitive transport? Or are you saying the routing/addressing architecture should do this for those applications that care? If it were always something that could be configured, things would be easy (or at least easier). At the moment, there are lots of places where determining the appropriate address to use is a matter for discovery. >>The second is the >>point I made in a previous post--that NATs or firewalls do not allow packets >>through to target end hosts until the flow has been enabled by action by the >>target (the "connectivity check" in ICE being the hook for that). >>If we don't >>deal with that somehow, having globally reachable addresses doesn't >>result in true local reachability no matter what. > >I think it would be a mistake to try to come up with an network routing/addressing architecture that attempts to defeat administratively defined policy. This is called an "arms race" and we'll lose. It's not the intent here to defeat administratively defined policy. The problem is that the current mechanism using NATs is using a tool that is not really policy driven; it's using a side-effect of the working of NATs, in effect, to get a policy result. Getting rid of NATs would likely push this into firewalls, but those are at least policy devices. Those could be upgraded in multiple ways to achieve the same ends without mucking with reachability to do it. >>>How important is the sort of hackery ICE is attempting to address? >>Assuming you mean the end result, rather than the specific mechanism, >>as important as VoIP. > >No, I meant the reason folks go and write protocols that making dealing with NAT hard are doing so for some set of reasons. Are those reasons permanent? How much of the hackery due to the desire to bypass administratively defined policy (e.g., tunnel everything through HTTP because nobody blocks HTTP)? I don't think I understand you here. Some applications-layer decisions clearly are made for the reasons you cite ; lots of uses of HTTP as a substrate are because the designers believe HTTP gets through firewalls (with deep packet inspection lots of those folks also later get nasty surprises). But most of the jiggery-pokery around NATs seems to be related to the many-to-few nature of common v4 NATs combined with the fact that NATs are placed administratively without any necessary relation to the routing system. You can't know, in particular, how many layers of NATs are between you and an intended peer, and you can't know which directions they "face" without corkscrewing around a lot. My personal reaction to that has been to try to imagine ways to make the context transitions which might replace these in an id/locator split world as obvious as possible. Using the same bit-pattern on both sides of the split, in particular, worries me greatly. But I suspect I am now very far off your question; can you clarify? regards, Ted >Rgds, >-drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 01:23:29 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxwf-0005N6-Sr; Wed, 04 Apr 2007 01:22:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HYxwf-0005N1-Bw for ram@iab.org; Wed, 04 Apr 2007 01:22:09 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HYxwe-0006Pq-DZ for ram@iab.org; Wed, 04 Apr 2007 01:22:09 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 210F359E41; Wed, 4 Apr 2007 15:22:06 +1000 (EST) Message-ID: <461335F1.8020908@firstpr.com.au> Date: Wed, 04 Apr 2007 15:21:53 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org References: DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> In-Reply-To: <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 1676547e4f33b5e63227e9c02bd359e3 Subject: [RAM] Re: LISP etc. is not the only path to scalable routing 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 David, I agree with all your concerns. I think the /24 limit on IPv4 is sufficient for the foreseeable future, since it could allow a much more flexible and intensive use of the address space than is currently the case. In the future, when bigger RAM chips are cheaper, this could be extended to /25 or /26. Some careful decisions would need to be made about IPv6, because the current global unicast range involves too many changing bits to map into SRAM. I think that a restricted range of global unicast addresses could still provide more than enough addresses for the next decade or so, after which a new standard for more SRAM and an extension of the range could be made. I wrote, and you disagreed with: > > This is not a case of "using more thrust". It is "more thrust", in the sense that it requires new routers in the DFZ, with a new design to a particular future standard. But in the timeframe I am suggesting, all those routers will need to be replaced anyway. I suggest a standard in 2007, new routers in 2009 or 2010 and ubiquitous deployment of the new routers (or old ones with massive TCAM etc.) by the end of 2014. I believe my proposal is not simply "more thrust", since the easiest way to achieve the proposed flat routing capability will involve low power consumption and moderate redesign with a standard SRAM chip, rather than complex new functions in ASICs or microcode or more and more TCAM. I think the result will be simpler, cheaper and less power-hungry than continuing to make larger versions of the current architecture for the next 10 to 20 years. I also think router manufacturers would implement SRAM in the way I describe anyway, irrespective of this proposal, because it is a cheaper alternative to massive TCAM for the task of likely future IPv4 DFZ traffic. I think they could be confident the /24 BGP limit will be extended to /25 or longer in the lifetime of the next generation of routers. A standard - or agreement - such as I am proposing would encourage this adoption of SRAM flat routing, especially if there was a standardised way of handling IPv6, perhaps in the 1/8 of the chip not needed for IPv4. More CPU and RAM thrust is required for the RIB and BPG traffic, as I acknowledged - but CPUs and SRAM/DRAM are commodity devices and are continually getting cheaper and faster - probably outpacing the current growth in the routing table. However, I expect SRAM-based flat routing would lead to greater rates of growth than in recent years. Compared to the task of turning RIB into TCAM (and its attached SRAM) data, it is trivially easy to convert the RIB into the FIB data in the SRAM. Updates to the SRAM FIB data are also simple and do not upset any other prefixes or delay the classification of packets. So in this respect, I think of the proposal as using more "elegant design" thrust and less "brute force hardware and complexity" thrust. > > *if* BGP and the router's CPUs can handle the required > > communications. You wrote: > That's part of the problem. People often say the problem is that > the "global routing table is too big". This is poor terminology > for many reasons, but mostly because the problem isn't the _size_ > of the table, but rather the flux and propagation of routing > information in conjunction with the need to lookup bits of that > information really really quickly. Your proposal (if I understand > it) addresses the latter bit. There is still the former bit. Yes. > > My understanding of instability in BGP is > > that it only affects the prefixes which are being changed. > > > I believe this depends on the type of instability, but there are > others on this list who can explore this in much more detail than > I. I hope someone with BGP expertise will confirm my guess that if a prefix is advertised at a different router to the one it was previously advertised at, that it may take time for the changes to propagate through the whole DFZ, as various routers reconfigure their RIB for this prefix - but that this does not affect the BGP traffic or forwarding of packets for other prefixes. > > One problem with assigning PI space to many more smaller AS > > end-users is that many more smaller prefixes will probably be > > poorly managed. > > Right. One advantage of a loc/id separation with mapping approach > is that it permits end "sites" (for some value of the variable > "site") to play in the multi-homing pond without having to also > play with BGP. As you note, the folks most likely to screw up BGP > are also most likely the folks who would have the long prefixes > being inserted into the routing system. BGP is sort of the soft > underbelly of the Internet... I agree. The SRAM-based flat routing system would enable very efficient, piecemeal, assignment of address space in small chunks. I intend that this encourage the direct connection of hundreds of thousands of AS networks, all with PI space for both IPv4 and IPv6. If this could be done, there would be tremendous benefits. However, it is likely that the global BGP system would need to be made more robust against badly managed border routers, against attacks and to discourage AS operators from changing their advertisements more rapidly, in general, than is deemed desirable by everyone else. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 05:18:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1bb-00012G-6o; Wed, 04 Apr 2007 05:16:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ1bZ-000127-P5 for ram@iab.org; Wed, 04 Apr 2007 05:16:37 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ1bY-0005ir-AZ for ram@iab.org; Wed, 04 Apr 2007 05:16:37 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 80EEA1986A2; Wed, 4 Apr 2007 12:16:32 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 4D2211986A0; Wed, 4 Apr 2007 12:16:32 +0300 (EEST) Message-ID: <4613599C.1060506@piuha.net> Date: Wed, 04 Apr 2007 10:54:04 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Re: Scaling target References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <46114E69.20901@cisco.com> <20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org> <46123624.50503@cisco.com> <46129A66.3080509@piuha.net> 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: 8b431ad66d60be2d47c7bfeb879db82c 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 David, > First cut: > - a way of (securely) creating the identifier/locator mapping > - a way of (securely) modifying the identifier/locator mapping > - a way of doing a lookup in and/or obtaining the identifier/locator > mapping > - a way of determining reachability and next hop for the destination > locator(s) > - in the case of multi-homed sites, a way of determining which of a > set of destination locators is "best" > - a way of (securely?) determining destination locator failure > - a way of coping with "legacy" addresses (this is the hardest part) Thanks for the list. > However, as I said in Amsterdam, "There Ain't No Such Thing As A Free > Lunch". There will be costs to _any_ approach taken. It isn't > sufficient to determine the costs of a single approach as any cost > must be judged relative to the costs of other approaches. Exactly -- that's why I asked about the costs. I realize very well that there are costs with the current path we are on, but I also want to see the costs associated with a new design. As you say, its the relation of the costs between the different approaches that counts. (And we should be saying "costs" in quotes, really, because we're not talking about money directly.) > Outside of some form of LOC/ID separation and PI to Everyone, what > other approaches are being actively explored? I think research on routing algorithms is needed, too. We already have host-based approaches which in my opinion are going to be needed at the SOHO end of the scale, and for very dynamic situations. Other than that, I don't see a lot of things that could change the situation in any fundamental way. Do you? But in addition we need to maintain, tune, and engineer our current systems better. And remember that it takes a long time to deploy something until it has an actual effect, e.g., in the table size. The efforts that I see in the short-term space include - hardware improvements and new types of designs (vendors are already doing this) - small BGP improvements that might affect, say, how well it deals with dynamics (rtgarea and idr are going to look at this) - operational practices Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:06:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4Ee-0003hI-Tx; Wed, 04 Apr 2007 08:05:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4Ed-0003dD-4R for ram@iab.org; Wed, 04 Apr 2007 08:05:07 -0400 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4Bp-0008AC-Cc for ram@iab.org; Wed, 04 Apr 2007 08:02:14 -0400 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 l34C28Cu172170 for ; Wed, 4 Apr 2007 12:02:08 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l34C27K52523312 for ; Wed, 4 Apr 2007 13:02:08 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l34C26b5026555 for ; Wed, 4 Apr 2007 13:02:07 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l34C26Zh026542; Wed, 4 Apr 2007 13:02:06 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA347100; Wed, 4 Apr 2007 14:02:03 +0200 Message-ID: <461393BC.4080105@zurich.ibm.com> Date: Wed, 04 Apr 2007 14:02:04 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Conrad Subject: Re: Thousands of large PI customers [Re: [RAM] Incremental Deploymentof LISP] References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <4610C965.8010208@zurich.ibm.com> <474EEBD229DF754FB83D256004D0210802584EAC@XCH-NW-6V1.nw.nos.boeing.com> <4611232A.2030006@zurich.ibm.com> <34BE7C0A-5A05-468C-B3E0-68D641BC819C@cisco.com> <7DF70F0B-A88E-4DD8-A9BA-845CF4B96EFE@cisco.com> <46124C0A.7040204@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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-04-03 18:47, David Conrad wrote: ... > > How would a push model work in the mobility case? It seems to me that in a foreign-agent c/o-address type of mobility there is no issue here: the id to be mapped is that of the FA, not that of the mobile host. Or another way to look at it is that MobileIP already solves the id/loc mapping problem using a rendezvous mechanism, where the rendezvous point is the home agent. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:22:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4VL-0000pK-3F; Wed, 04 Apr 2007 08:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4VK-0000pE-8k for ram@iab.org; Wed, 04 Apr 2007 08:22:22 -0400 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4VI-0006Bk-Qv for ram@iab.org; Wed, 04 Apr 2007 08:22:22 -0400 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 l34CMJ9E064468 for ; Wed, 4 Apr 2007 12:22:19 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.3) with ESMTP id l34CMJoC2773078 for ; Wed, 4 Apr 2007 13:22:19 +0100 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 l34CMJb9024358 for ; Wed, 4 Apr 2007 13:22:19 +0100 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 l34CMJWM024353; Wed, 4 Apr 2007 13:22:19 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA342766; Wed, 4 Apr 2007 14:22:18 +0200 Message-ID: <4613987A.6080806@zurich.ibm.com> Date: Wed, 04 Apr 2007 14:22:18 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: David Conrad Subject: Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774873@XCH-NW-7V2.nw.nos.boeing.com> <5DA18A74-7B82-44F6-9046-BFE30BD8F0AD@virtualized.org> <68BE7589-C868-49FC-849B-976B61D10434@cisco.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: Tony Li , 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-04-04 03:24, David Conrad wrote: > Tony, > > On Apr 3, 2007, at 2:02 PM, Tony Li wrote: >>> Maybe it's me, but I don't really see a demand for host-based >>> solutions. I see a demand for "site"-based solutions. >> Interesting. I've only seen a rejection of host-by-host managed >> solutions. I haven't seen anything that required a site based >> solution. It seems to me that some site-managed host based solution >> is NOT out of the question. Data? > > I was speaking only of my experience. In the various discussions I've > had, I've only had a few folks indicate they thought a host-based > solution (that is, a solution that requires host-level configuration) > was the right way to go. I suppose a site-managed host based solution > would be workable, albeit I personally would be concerned about the > additional complexity (management and/or software) this would imply. There's no doubt that for the host-based solution I know best, shim6, a serious sized site would need policy control of some kind - most likely based on pushing an RFC3484-like address selection policy, which could be used indirectly to control exit router selection. For a SOHO site, I doubt that would be needed. For a large site, PI would work better. The point is that in all cases the end user couldn't care less. There might be a couple of boxes to check but most likely the config would be default. The IT department would have to do some config, of course. I think the real question is how much control the corporate IT department needs and how much control the ISP needs. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:27:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ZH-000517-I1; Wed, 04 Apr 2007 08:26:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ZG-000510-7d for ram@iab.org; Wed, 04 Apr 2007 08:26:26 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4ZC-0007bL-0I for ram@iab.org; Wed, 04 Apr 2007 08:26:26 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 1FF6586AF1; Wed, 4 Apr 2007 08:26:20 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Re: LISP etc. is not the only path to scalable routing Message-Id: <20070404122620.1FF6586AF1@mercury.lcs.mit.edu> Date: Wed, 4 Apr 2007 08:26:20 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: Robin Whittle > I think the result will be simpler, cheaper and less power-hungry than > continuing to make larger versions of the current architecture for the > next 10 to 20 years. I am reliably informed (i.e. by someone who builds them for a living) that the vast majority (I don't recall the specific number, but it's on the order of 75% or so) of the gates (and heat/power) in contemporary large routers are consumed by the forwarding, and in particular things like access controls. The RIB and/or FIB are not the issue. > More CPU and RAM thrust is required for the RIB and BPG traffic > .. but CPUs and SRAM/DRAM are commodity devices and are continually > getting cheaper and faster - probably outpacing the current growth in > the routing table. No, not really. For one, I am told that it takes a core router (i.e. one with complete routing table) a significant fraction of an hour to load the current complete routing table (via BGP) when it restarts; this clearly indicates poor dynamic response. And as other people have already mentioned, but this discussion doesn't seem to be taking on board, the most troubling issue with routing is not the static situation (i.e. table size when things are quiet), but the dynamic situation (i.e. how promptly the routing responds, *and stabilizes*, when there's a topology change). The following presentation might be helpful in terms of making this point: Quaking Tables: The Taiwan Earthquakes and the Internet Routing Table http://www.nanog.org/mtg-0702/presentations/underwood.pdf The summary on the slide labelled "Timeline (2)" is particularly instructive. > However, I expect SRAM-based flat routing would lead to greater rates > of growth than in recent years. In light of the above, this statement is particularly problematic. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4hb-0001zT-Nc; Wed, 04 Apr 2007 08:35:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ha-0001y0-7a for ram@iab.org; Wed, 04 Apr 2007 08:35:02 -0400 Received: from mtagate8.uk.ibm.com ([195.212.29.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4hE-0001df-5p for ram@iab.org; Wed, 04 Apr 2007 08:34:41 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l34CYXAS263938 for ; Wed, 4 Apr 2007 12:34:33 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.3) with ESMTP id l34CYX1h2773218 for ; Wed, 4 Apr 2007 13:34:33 +0100 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 l34CYWZh021838 for ; Wed, 4 Apr 2007 13:34:33 +0100 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 l34CYWvk021828; Wed, 4 Apr 2007 13:34:32 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA302664; Wed, 4 Apr 2007 14:34:29 +0200 Message-ID: <46139B56.5000202@zurich.ibm.com> Date: Wed, 04 Apr 2007 14:34:30 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Re: LISP etc. is not the only path to scalable routing References: DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> In-Reply-To: <461335F1.8020908@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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-04-04 07:21, Robin Whittle wrote: ... > Some careful decisions would need to be made about IPv6, because the > current global unicast range involves too many changing bits to map > into SRAM. There's a reason for that. Because of the address shortage, we have been forced over the last 15 years to use IPv4 space extremely conservatively, avoiding sparse allocation at all costs. One of the drivers for the choice of 128 bits for IPv6 (rather than say 64) was to avoid this artificial pressure for compact allocation. Sparse allocation is much less annoying for sites, since it's much less likely to lead to churn in an addressing plan (which is an even bigger pain point than simple prefix renumbering). Or in other words, the IPv6 equivalent of a /24 is a /48 or even a /56. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4hc-000204-4S; Wed, 04 Apr 2007 08:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ha-0001yK-EA for ram@iab.org; Wed, 04 Apr 2007 08:35:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4gW-0000fq-Mp for ram@iab.org; Wed, 04 Apr 2007 08:33:58 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4E3E3198688; Wed, 4 Apr 2007 15:33:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D1CAA198684; Wed, 4 Apr 2007 15:33:52 +0300 (EEST) Message-ID: <46139B31.6000306@piuha.net> Date: Wed, 04 Apr 2007 15:33:53 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Russ White Subject: Re: [RAM] MANETs and LISP References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> <46119A6D.7070208@cisco.com> In-Reply-To: <46119A6D.7070208@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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Fleischman, Eric" , 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 > If you try to actually figure out how LISP of any type would work _in_ a > MANET, rather than with a MANET attached to it, you'll face much larger > challenges, though. As long as the network locators remain stable, we > are being told LISP will reduce the churn in the network. I'm not at all > convinced of this, but let's run with it a second, and see where it leads. > > Now, when the locators and the IDs are in constant flux, then the > mapping system between the two has to deal with churn on both sides, not > just one, and things don't line up so nicely. First, I think Eric had a point in keeping some amount of separation between MANET techniques and the techniques needed in the global Internet. If the global network topology stays relatively static, it makes sense to tailor the global routing mechanisms for that situation. But it is a feature, not a bug that independent networks on the edges can choose to run mechanisms that suit their specific needs, ranging from manual configuration to MANETs. However, there is a general issue with churn that probably deserves some discussion. Clearly, we want the core of the network to be relatively stable, and if it employs only PA addressing that is a big step towards stability in the core BGP table. But I'd like to understand to what extent this change solves the churn issues that we are seeing today -- presumably there are other reasons for this beyond, say, TE related to PI space. Do we understand whether those other reasons will still create enough churn to worry about? Another question is the stability of the new mapping table that proposals such as EFIT or LISP need. Since this table has (ID, LOC) entries, it depends on the stability of the identifiers and locators. Lets talk about the locator part first: - Change or addition of a provider serving this network results in a mapping change. This is expected to be a relatively slow process. - "TE" needs might require updating attributes associated with the mapping (such as the order of locators). If there is such a need, it is likely to result in much more frequent changes than the above one. (I'm just trying to establish how fast the data changes, not say anything about the implementation. Clearly you could store information either in a database or communicate between the peers, for instance.) - If the goal is to support network mobility as well, then the requirements become significantly more demanding. To support this at a rate where you would drop no voice packets or at most few packets upon movement is hard. Basically, neither push or pull would suffice, though pull + reactive updates might. Identifier part: - Network re-design, organizational mergers/splits, etc. likely results in some changes to the identifiers, use of multiple identifiers, splitting identifier spaces, etc. This is again expected to be a relatively slow process. - If the identifier database holds "identifier prefixes", then it changes only as the entire network changes. But if it points to specific identifiers it becomes bigger, and requires changes as hosts are added, removed, or move around from one network to another. - But movement of the hosts within the network does not impact the global mapping table at all -- irrespective of whether the network employs OSPF or MANET routing protocols. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4hb-0001zT-Nc; Wed, 04 Apr 2007 08:35:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ha-0001y0-7a for ram@iab.org; Wed, 04 Apr 2007 08:35:02 -0400 Received: from mtagate8.uk.ibm.com ([195.212.29.141]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4hE-0001df-5p for ram@iab.org; Wed, 04 Apr 2007 08:34:41 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate8.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l34CYXAS263938 for ; Wed, 4 Apr 2007 12:34:33 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.3) with ESMTP id l34CYX1h2773218 for ; Wed, 4 Apr 2007 13:34:33 +0100 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 l34CYWZh021838 for ; Wed, 4 Apr 2007 13:34:33 +0100 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 l34CYWvk021828; Wed, 4 Apr 2007 13:34:32 +0100 Received: from [9.4.210.54] ([9.4.210.54]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA302664; Wed, 4 Apr 2007 14:34:29 +0200 Message-ID: <46139B56.5000202@zurich.ibm.com> Date: Wed, 04 Apr 2007 14:34:30 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Re: LISP etc. is not the only path to scalable routing References: DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> In-Reply-To: <461335F1.8020908@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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-04-04 07:21, Robin Whittle wrote: ... > Some careful decisions would need to be made about IPv6, because the > current global unicast range involves too many changing bits to map > into SRAM. There's a reason for that. Because of the address shortage, we have been forced over the last 15 years to use IPv4 space extremely conservatively, avoiding sparse allocation at all costs. One of the drivers for the choice of 128 bits for IPv6 (rather than say 64) was to avoid this artificial pressure for compact allocation. Sparse allocation is much less annoying for sites, since it's much less likely to lead to churn in an addressing plan (which is an even bigger pain point than simple prefix renumbering). Or in other words, the IPv6 equivalent of a /24 is a /48 or even a /56. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 08:35:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4hc-000204-4S; Wed, 04 Apr 2007 08:35:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ4ha-0001yK-EA for ram@iab.org; Wed, 04 Apr 2007 08:35:02 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ4gW-0000fq-Mp for ram@iab.org; Wed, 04 Apr 2007 08:33:58 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id 4E3E3198688; Wed, 4 Apr 2007 15:33:53 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id D1CAA198684; Wed, 4 Apr 2007 15:33:52 +0300 (EEST) Message-ID: <46139B31.6000306@piuha.net> Date: Wed, 04 Apr 2007 15:33:53 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Russ White Subject: Re: [RAM] MANETs and LISP References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com> <46119A6D.7070208@cisco.com> In-Reply-To: <46119A6D.7070208@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: d8ae4fd88fcaf47c1a71c804d04f413d Cc: "Fleischman, Eric" , 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 > If you try to actually figure out how LISP of any type would work _in_ a > MANET, rather than with a MANET attached to it, you'll face much larger > challenges, though. As long as the network locators remain stable, we > are being told LISP will reduce the churn in the network. I'm not at all > convinced of this, but let's run with it a second, and see where it leads. > > Now, when the locators and the IDs are in constant flux, then the > mapping system between the two has to deal with churn on both sides, not > just one, and things don't line up so nicely. First, I think Eric had a point in keeping some amount of separation between MANET techniques and the techniques needed in the global Internet. If the global network topology stays relatively static, it makes sense to tailor the global routing mechanisms for that situation. But it is a feature, not a bug that independent networks on the edges can choose to run mechanisms that suit their specific needs, ranging from manual configuration to MANETs. However, there is a general issue with churn that probably deserves some discussion. Clearly, we want the core of the network to be relatively stable, and if it employs only PA addressing that is a big step towards stability in the core BGP table. But I'd like to understand to what extent this change solves the churn issues that we are seeing today -- presumably there are other reasons for this beyond, say, TE related to PI space. Do we understand whether those other reasons will still create enough churn to worry about? Another question is the stability of the new mapping table that proposals such as EFIT or LISP need. Since this table has (ID, LOC) entries, it depends on the stability of the identifiers and locators. Lets talk about the locator part first: - Change or addition of a provider serving this network results in a mapping change. This is expected to be a relatively slow process. - "TE" needs might require updating attributes associated with the mapping (such as the order of locators). If there is such a need, it is likely to result in much more frequent changes than the above one. (I'm just trying to establish how fast the data changes, not say anything about the implementation. Clearly you could store information either in a database or communicate between the peers, for instance.) - If the goal is to support network mobility as well, then the requirements become significantly more demanding. To support this at a rate where you would drop no voice packets or at most few packets upon movement is hard. Basically, neither push or pull would suffice, though pull + reactive updates might. Identifier part: - Network re-design, organizational mergers/splits, etc. likely results in some changes to the identifiers, use of multiple identifiers, splitting identifier spaces, etc. This is again expected to be a relatively slow process. - If the identifier database holds "identifier prefixes", then it changes only as the entire network changes. But if it points to specific identifiers it becomes bigger, and requires changes as hosts are added, removed, or move around from one network to another. - But movement of the hosts within the network does not impact the global mapping table at all -- irrespective of whether the network employs OSPF or MANET routing protocols. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 10:41:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6dh-0003o2-PC; Wed, 04 Apr 2007 10:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ6df-0003kW-JF for ram@iab.org; Wed, 04 Apr 2007 10:39:07 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZ6de-00030X-CK for ram@iab.org; Wed, 04 Apr 2007 10:39:07 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id EC11B872CA; Wed, 4 Apr 2007 10:39:03 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] LISP and the Global Internet Architecture Message-Id: <20070404143903.EC11B872CA@mercury.lcs.mit.edu> Date: Wed, 4 Apr 2007 10:39:03 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: David Conrad > On Apr 2, 2007, at 7:08 PM, Noel Chiappa wrote: >> Which leads me to wonder what the future really is, though. What >> happens when the IPv4 addresses really do start to run out in a few >> years? Will we see a market develop for IPv4 addresses, plus >> continued use of NAT? > Yes. And this will drive increased fragmentation of the routing > space, resulting in increased routing information load. Excellent point. An architectural addition of a mapping from identifiers to locators will really help deal with this; fragmentation of what is (mostly) a pure identifier-space wouldn't be anything as problematic, I suspect. As a generic point, we have to deal with the network we actually have, not the network we wish we had... Which leads me to another thought, having to do with migration of endpoint identification (or, more generally, end-end naming) to a new namespace. (As Jim Bound suggested, we probably want to migrate *both* existing uses of IPv4 "addresses" to new namespaces.) Deployment of a "jack-up" design will give us a new locator namespace, but it leaves the hard job: migration of the endpoint naming functionality, which necessarily involves touching the hosts. One theory I've had for some years now is that we won't be able to deploy a whole new end-end namespace at the transport level, because there is simply too much deployed base. (".. we have to deal with the network we actually have ..") Rather, we'll only be able to deploy new namespaces on a per-application basis: we see this now with the way the WWW uses cookies. The WWW naming system is "NAT-friendly", in that as far as WWW interactions are concerned, the IPv4 addresses are simply local forwarding tags (which is what I see the long-term future of IPv4 addresses being). So perhaps that, plus continued use of NAT in end-end naming for legacy applications, is what the future looks like... Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 11:22:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7IS-00028I-N7; Wed, 04 Apr 2007 11:21:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZ7IR-00026Y-HV for ram@iab.org; Wed, 04 Apr 2007 11:21:15 -0400 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 1HZ7IJ-0001E6-43 for ram@iab.org; Wed, 04 Apr 2007 11:21:15 -0400 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 l34FL35f011801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2007 08:21:04 -0700 (PDT) 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 l34FL3cp010599; Wed, 4 Apr 2007 08:21:03 -0700 (PDT) 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 l34FL2DW010564; Wed, 4 Apr 2007 08:21:03 -0700 (PDT) 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, 4 Apr 2007 08:21:01 -0700 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] MANETs and LISP Date: Wed, 4 Apr 2007 08:20:19 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A101774887@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46139B31.6000306@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] MANETs and LISP Thread-Index: Acd2tbto3kuvBCmDTcmGBXG+rJM8LwAFsj9A References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com><474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAD@XCH-NW-6V1.nw.nos.boeing.com><46119A6D.7070208@cisco.com> <46139B31.6000306@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" X-OriginalArrivalTime: 04 Apr 2007 15:21:01.0221 (UTC) FILETIME=[DA5BE550:01C776CC] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 > - If the goal is to support network mobility as well, then the > requirements become significantly more demanding. To > support this at a rate where you would drop no voice packets > or at most few packets upon movement is hard. Basically, > neither push or pull would suffice, though pull + reactive > updates might. One alternative for pull + reactive would be DNS + MOBIKE. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 15:50:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBTX-0001An-A6; Wed, 04 Apr 2007 15:48:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBTV-0000ym-QU for ram@iab.org; Wed, 04 Apr 2007 15:48:57 -0400 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBTT-0000jk-HS for ram@iab.org; Wed, 04 Apr 2007 15:48:57 -0400 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 946BF7946 for ; Wed, 4 Apr 2007 12:48:42 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <90AA145B-4D81-4432-BBD7-7FBD3F0449E6@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Wed, 4 Apr 2007 15:48:40 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Subject: [RAM] Suggested Reading 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 Article: XQ Meng & others, "IPv4 address allocation and the BGP routing table evolution", ACM Computer Communications Review, Volume 35, Number 1, pp. 71-80, January 2005. ACM SIGCOMM. URL for PDF: http://www.cs.ucla.edu/~lixia/papers/05CCR_RoutTable.pdf My Comments: Figure 15 is particularly useful in helping to categorise deployment patterns of more specific prefix advertisements. Table 1 is particularly helpful in mapping those diagrams into likely operational reasons for each of those patterns to appear in the operational Internet. Figure 16 is particularly helpful in taking a snapshot of more specific prefixes and analysing what percentage of prefixes had which likely root causes. My Conclusion: We really need better mechanisms to enable site/subnetwork/host multi-homing if we want to reduce the growth of more specific IP prefix advertisements through BGP. Please accept apologies for using data in discussions on this list. Yours, Ran Atkinson rja@extremenetworks.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 15:55:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBZX-0000tm-0c; Wed, 04 Apr 2007 15:55:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBZW-0000tO-1A for ram@iab.org; Wed, 04 Apr 2007 15:55:10 -0400 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 1HZBZ1-0002bq-Tv for ram@iab.org; Wed, 04 Apr 2007 15:55:10 -0400 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 l34JsZg8021166 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2007 12:54:36 -0700 (PDT) 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 l34JsZVa004721; Wed, 4 Apr 2007 12:54:35 -0700 (PDT) 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 l34JsTN5004434; Wed, 4 Apr 2007 12:54:31 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 12:54:29 -0700 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: Scaling target Date: Wed, 4 Apr 2007 12:54:29 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584ED3@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Re: Scaling target Thread-Index: Acd2DvZo7rahM8XmT1iGsFcBZ0Vh/gA4oGiw References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><46114E69.20901@cisco.com><20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org><46123624.50503@cisco.com> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 04 Apr 2007 19:54:29.0705 (UTC) FILETIME=[0E93DB90:01C776F3] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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'm not tracking with you here, David. If LISP truly offers an EID-locator split as claimed, why would the address space the end user uses (the EID) affect the address space the ISPs doing Internet routing use (the locator)? That is, LISP promises to decouple local addressing issues from global addressing issues. If so, then what is to stop your SOHO from switching ISPs while retaining your original PA addresses -- or do you need to internally switch to a private address space (e.g., Net10) to get such decoupling? -----Original Message----- From: David Conrad [mailto:drc@virtualized.org]=20 > Why don't they just continue to use the PA space and let the SPs=20 > handle any LISP. Because multi-homing with PA is hard and annoying. My assumption is that people are going to be more and more dependent on Internet connectivity in the future (not only for data, but also VoIP, TV/movies-over-Internet, home security monitoring, home automation, etc). With dependency comes demand for increased reliability. I believe this demand for reliability will drive increased requirements for multi-homing, particularly in the residential markets and particularly via multiple high speed wireless providers. A locator/ID split solution would allow _anyone_ to be provider independent and to multi-home without having to know BGP. I can easily imagine Internet service becoming commodity in the sense that =20 customers change providers rapidly as costs/load/performance shifts. =20 Try doing that with PA. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 16:20:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBx4-0001DY-Ux; Wed, 04 Apr 2007 16:19:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZBx3-0001DE-8k for ram@iab.org; Wed, 04 Apr 2007 16:19:29 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZBww-0007z7-1i for ram@iab.org; Wed, 04 Apr 2007 16:19:29 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l34KJB1o018218 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Apr 2007 13:19:11 -0700 (PDT) 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 l34KJA8b025603; Wed, 4 Apr 2007 13:19:10 -0700 (PDT) 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 l34KJA6G025597; Wed, 4 Apr 2007 13:19:10 -0700 (PDT) Received: from XCH-NW-6V1.nw.nos.boeing.com ([130.247.55.53]) by XCH-NWBH-11.nw.nos.boeing.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Apr 2007 13:19:09 -0700 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] LISP and the Global Internet Architecture Date: Wed, 4 Apr 2007 13:19:09 -0700 Message-ID: <474EEBD229DF754FB83D256004D0210802584ED6@XCH-NW-6V1.nw.nos.boeing.com> In-Reply-To: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP and the Global Internet Architecture Thread-Index: Acd1lPfG1Q/6AHJ/Q/adjVRDV5avqgBYKYpQ References: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> From: "Fleischman, Eric" To: , X-OriginalArrivalTime: 04 Apr 2007 20:19:09.0989 (UTC) FILETIME=[80E54550:01C776F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 Noel, As long as our community fails to share a common Internet Architecture together then we are doomed to incremental add ons, even poorly justified ones.=20 LISP is being proposed to become a new consensus architecture for us. Now is therefore the time to do good fundamentals-based engineering because if LISP is inadequate to be our architecture, then we would be very poorly served by trying to build upon it. However, my point was that fundamentals-based engineering is only part of the story. The approach selected cannot be inherently self-defeating if we hope for it to actually achieve our goals. --Eric -----Original Message----- From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu]=20 Sent: Monday, April 02, 2007 7:08 PM To: ram@iab.org Cc: jnc@mercury.lcs.mit.edu Subject: RE: [RAM] LISP and the Global Internet Architecture > From: "Fleischman, Eric" > until IPv6 permitted PI addresses, it represented a mechanism that > required large end users to be held captive to their ISPs. This is > untenable to any end user and violates a fundamental law of economics > that businesses support the needs of their customers. This was certainly not the intent, or reason, that location-based addressing was put forward; rather, it was principally motivated by technical considerations. ("PA" is just a post-hoc label applied to something that came from technical considerations, hence its original names - "location-based addressing" or "connectivity-based addressing".) You are correct that it had economic consequences that either weren't adequately considered, or taken into account (or perhaps both), at the time. I think the whole IPv6 experience (and not just the PA/PI thing) has made us all much more sensitive to the need to try and understand the economics of the proposed deployment of any new stuff. Which leads me to wonder what the future really is, though. What happens when the IPv4 addresses really do start to run out in a few years? Will we see a market develop for IPv4 addresses, plus continued use of NAT? Or will uSoft's attempt to drive IPv6 deployment by including it in Vista succeed? And even more importantly, is there really any scope left for good fundamentals-based engineering, or will we always be restricted by economic/business considerations to the cheapest thing we can possibly come up with that more or less kludges the network into continued operation? Maybe it's time to switch out of networking (or just plain retire and take up building furniture :-). Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 16:33: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 1HZC9u-0006sv-G4; Wed, 04 Apr 2007 16:32:46 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZC9t-0006so-Lb for ram@iab.org; Wed, 04 Apr 2007 16:32:45 -0400 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HZC9p-00088J-57 for ram@iab.org; Wed, 04 Apr 2007 16:32:45 -0400 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 933F67946 for ; Wed, 4 Apr 2007 13:00:15 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Wed, 4 Apr 2007 16:00:13 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [RAM] More suggested reading 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 was not in Prague, but there seem to have been some BGP-related presentations at the IEPG meeting. These are now available online, mostly in PDF. http://www.iepg.org/march2007/index.html The really brave might also want to peruse past IEPG meetings for related presentations -- or even NANOG meeting archives. IEPG http://www.iepg.org NANOG http://www.nanog.org Again, please accept my apologies for providing references to actual measured data, rather than offering speculation without any measured data. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 17:50:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDLZ-0005UM-1o; Wed, 04 Apr 2007 17:48:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZDLX-0005UH-Sw for ram@iab.org; Wed, 04 Apr 2007 17:48:51 -0400 Received: from ns.virtualized.org ([204.152.189.134] helo=mail.virtualized.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZDLW-0004vV-HQ for ram@iab.org; Wed, 04 Apr 2007 17:48:51 -0400 Received: from terminus.local (ns.virtualized.org [204.152.189.134]) by mail.virtualized.org (8.12.9p1/8.12.9) with ESMTP id l34LYS61041123; Wed, 4 Apr 2007 14:34:37 -0700 (PDT) (envelope-from drc@virtualized.org) Received: from [127.0.0.1] by terminus.local (PGP Universal service); Wed, 04 Apr 2007 14:48:15 -0700 X-PGP-Universal: processed; by terminus.local on Wed, 04 Apr 2007 14:48:15 -0700 In-Reply-To: <474EEBD229DF754FB83D256004D0210802584ED3@XCH-NW-6V1.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><46114E69.20901@cisco.com><20B36603-B347-4FDB-8269-D6C800B3C692@virtualized.org><46123624.50503@cisco.com> <474EEBD229DF754FB83D256004D0210802584ED3@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v752.3) Message-Id: <562BEB4B-A42C-4EBD-96EE-D8921DBF1D09@virtualized.org> From: David Conrad Subject: Re: [RAM] Re: Scaling target Date: Wed, 4 Apr 2007 14:48:05 -0700 To: "Fleischman, Eric" X-Mailer: Apple Mail (2.752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Eric, On Apr 4, 2007, at 12:54 PM, Fleischman, Eric wrote: > If LISP truly offers an > EID-locator split as claimed, To be clear, I'm talking about generic locator/id splits, not necessarily the specific instantiation of that split that is LISP (that is, I haven't thought deeply enough about LISP to see where it doesn't fit the model that I have in my head if anywhere, so I can't claim to speak about LISP specifically). > why would the address space the end user > uses (the EID) affect the address space the ISPs doing Internet > routing > use (the locator)? It doesn't. That's the point. > That is, LISP promises to decouple local addressing issues from > global addressing issues. Right. > If so, then what is to stop your > SOHO from switching ISPs while retaining your original PA addresses -- Because by definition, PA address space is connectivity based. You get it from your ISP and must return it to that ISP when you change ISPs. > or do you need to internally switch to a private address space (e.g., > Net10) to get such decoupling? EID space is, by definition, decoupled from locator space (and locator space is, of course, provider aggregatable). Rgds, -drc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 04 23:33:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZIfh-0006qL-AF; Wed, 04 Apr 2007 23:30:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZIff-0006ps-M7 for ram@iab.org; Wed, 04 Apr 2007 23:29:59 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZIfe-0002st-Dz for ram@iab.org; Wed, 04 Apr 2007 23:29:59 -0400 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 8036817BD6; Thu, 5 Apr 2007 05:29:57 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Apr 2007 05:30:12 +0200 To: Brian E Carpenter From: JFC Morfin Subject: Re: [RAM] LISP and the Global Internet Architecture In-Reply-To: <461240C0.8040100@zurich.ibm.com> References: <474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com> <22000.61535.qm@web58714.mail.re1.yahoo.com> <474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB1@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EB6@XCH-NW-6V1.nw.nos.boeing.com> <46119E04.60107@cisco.com> <60C4A248E730F249990993E3B9BD44D803525C68@xmb-sjc-218.amer.cisco.com> <461240C0.8040100@zurich.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070405032957.8036817BD6@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 13:55 03/04/2007, Brian E Carpenter said: >Except that with IPv6, you need neither LISP nor internal NATs to merge >address spaces. As has been observed, the main win in IPv6 is having >enough address space, so that collision isn't an issue and NAT isn't a >requirement. Unfortunately I must disagree. As it is documented today IPv6: - does not permit (except if my proposition is supported by a separate /3 blok) to orthogonally support world location, addressing and local identification numbering plans (only IPv6 under LISP permits a world identification scheme) - does not document the user space organisation, removing most of the application developper/user interest into its use at this stage. Does not permit alone (chained IPv6 under LISP permits it) to address very wide address plans as most probably required in coming quantic and space related processes and communications. Cheers. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 05 00:20:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZJS2-0003Ib-Ez; Thu, 05 Apr 2007 00:19:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZJS1-0003IV-Dt for ram@iab.org; Thu, 05 Apr 2007 00:19:57 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZJRz-0002YH-Vs for ram@iab.org; Thu, 05 Apr 2007 00:19:57 -0400 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 D5DA117BA4; Thu, 5 Apr 2007 06:19:54 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 05 Apr 2007 06:20:10 +0200 To: "Fleischman, Eric" , , From: JFC Morfin Subject: RE: [RAM] LISP and the Global Internet Architecture In-Reply-To: <474EEBD229DF754FB83D256004D0210802584ED6@XCH-NW-6V1.nw.nos .boeing.com> References: <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> <474EEBD229DF754FB83D256004D0210802584ED6@XCH-NW-6V1.nw.nos.boeing.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070405041954.D5DA117BA4@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 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 Dear Eric and Noel, you are Internet designers. I am a forced user of it. I am glad you share my judgment, but I am less pessimitic than you. At 22:19 04/04/2007, Fleischman, Eric wrote: >However, my point was that fundamentals-based engineering is only >part of the story. The approach selected cannot be inherently >self-defeating if we hope for it to actually achieve our goals. IMHO IAB addressed this very well in RFC 3869. However, the IETF was absent when the response was discussed, at the WSIS and IGF. By its own decision. This may still be addressed. Why not to run a common workshop in Rio to tell the people the truth and get the support we need. The support we need is actually not money, but simply attention. >From: Noel Chiappa [mailto:jnc@mercury.lcs.mit.edu] >Sent: Monday, April 02, 2007 7:08 PM >To: ram@iab.org >Cc: jnc@mercury.lcs.mit.edu >Subject: RE: [RAM] LISP and the Global Internet Architecture >I think the whole IPv6 experience (and not just the PA/PI thing) has >made us all much more sensitive to the need to try and understand the >economics of the proposed deployment of any new stuff. Yes, 15 years are a long time to understand what CCITT voted in 1983. >Which leads me to wonder what the future really is, though. What happens >when the IPv4 addresses really do start to run out in a few years? Will >we see a market develop for IPv4 addresses, plus continued use of NAT? IPv8 was the likely solution. Wild LISP is now a better possibility. >Or will uSoft's attempt to drive IPv6 deployment by including it in >Vista succeed? > >And even more importantly, is there really any scope left for good >fundamentals-based engineering, or will we always be restricted by >economic/business considerations to the cheapest thing we can possibly >come up with that more or less kludges the network into continued >operation? > >Maybe it's time to switch out of networking (or just plain retire and >take up building furniture :-). May I suggest that the problem is that for too long the IETF culture has tried to address modelisation and architectural issues as if they were fundamental engineering. How can people move from IESG to IAB. These are two different trades. By definition the best architecture is the one which is the most elegant, hence the cheapest, to address the market needs. User inputs are usually a good help to find it more quickly. In our new society, it happens that lead users are progressively able to carry the innovation. However, a discussion with Stallman yesterday shown me the limitations that our own solutions impose on us. This started with IETF rought consensus and GNU licenses. They were good at the begining, they are the limitation factor now because it turns out that they do not technically and economically scale. The same for engineering without architecturing. New Internet Architecture is necessary in every dimension of the network architecture (naming, addressing, routing, protocols, etc.). Once the first alert has been patched via CIDR, http.1.1 and NATs, the next key necessity was languages. IETF tried to patch it through IDNA and RFC 4646. PR-acting me was its solution to patch this architectural issue :-). Unfortunately it failed: shutting me-up was nothing compared with the coming multilingual TLD and indexing compounded issues. etc. and the following resulting identification issue, which in turn will fire the fuse of addressing once again. May be the best would be to PR-action LISP :-) What worries me is that round the world Telcos are switching to TCP/IP, US DoD was supposed to have entirely switched to IPv6 before July 2008, etc. jfc _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 05 03:24:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMHb-0002rx-R9; Thu, 05 Apr 2007 03:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZMHa-0002rp-RT for ram@iab.org; Thu, 05 Apr 2007 03:21:22 -0400 Received: from moebius2.space.net ([195.30.1.100]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1HZMHZ-0001b5-EJ for ram@iab.org; Thu, 05 Apr 2007 03:21:22 -0400 Received: (qmail 91910 invoked by uid 1007); 5 Apr 2007 07:21:03 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=testkey; d=space.net; b=Eyf1WRNJkLZqHZBt9O1Y/DeOyTifLuqVbUgB17Zs7YlezlggugNRRPGmQRm890fZ ; Date: Thu, 5 Apr 2007 09:21:03 +0200 From: Gert Doering To: HeinerHummel@aol.com Subject: Re: [RAM] Incremental Deployment of LISP Message-ID: <20070405072103.GC63243@Space.Net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.1i X-NCC-RegID: de.space X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: jnc@mercury.lcs.mit.edu, 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, On Thu, Mar 29, 2007 at 04:14:55PM -0400, HeinerHummel@aol.com wrote: > How about a new routing protocol and a new IPvN which a) overcomes all the > scalability problems and catches up with postal letter forwarding as done for > centuries with two parts written on the envelope: 1) Name of receiver (plus > Mr. or Mrs,...) > > and maybe a little bit lower 2) street and number, zipcode and city, plus > country. > > As a kid when I learned where to place these parts, I had no idea about > endpoint identifier /locator split :-) Actually, this isn't really an id-loc split thing, but instead a very strict hierarchical routing system. If you move to a different place, you have to renumber... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 98999 SpaceNet AG Vorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444 USt-IdNr.: DE813185279 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 06 10:26:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpMp-0001xZ-LQ; Fri, 06 Apr 2007 10:24:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZpMo-0001xR-EQ for ram@iab.org; Fri, 06 Apr 2007 10:24:42 -0400 Received: from e34.co.us.ibm.com ([32.97.110.152]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpMl-00061g-WB for ram@iab.org; Fri, 06 Apr 2007 10:24:42 -0400 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e34.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l36EOdIO011086 for ; Fri, 6 Apr 2007 10:24:39 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l36EOccW185536 for ; Fri, 6 Apr 2007 08:24:38 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l36EOc5U023407 for ; Fri, 6 Apr 2007 08:24:38 -0600 Received: from cichlid.raleigh.ibm.com (wecm-9-67-146-181.wecm.ibm.com [9.67.146.181]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l36EOZuE023225 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 6 Apr 2007 08:24:37 -0600 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l36EOSPi032112 for ; Fri, 6 Apr 2007 10:24:29 -0400 Message-Id: <200704061424.l36EOSPi032112@cichlid.raleigh.ibm.com> To: ram@iab.org Date: Fri, 06 Apr 2007 10:24:28 -0400 From: Thomas Narten X-Spam-Score: 1.4 (+) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Subject: [RAM] Weekly posting summary for 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. I've been collecting mail list stats for a while, but have not posted them until today. But I'm hearing from folk that they can't keep up with this list, and the count for the week is quite high. Please be considerate and make your postings count (often, less is more). No one benefits if people quit reading messages due to overload. Thomas Total of 235 messages in the last 7 days. script run at: Fri Apr 6 00:53:03 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 11.49% | 27 | 10.91% | 154679 | drc@virtualized.org 9.79% | 23 | 9.53% | 135104 | fred.l.templin@boeing.com 9.79% | 23 | 9.13% | 129416 | rdobbins@cisco.com 7.23% | 17 | 7.57% | 107347 | dino@cisco.com 6.81% | 16 | 6.67% | 94582 | lear@cisco.com 6.38% | 15 | 6.29% | 89183 | tli@cisco.com 6.38% | 15 | 6.17% | 87506 | brc@zurich.ibm.com 5.53% | 13 | 6.42% | 90965 | eric.fleischman@boeing.com 4.26% | 10 | 3.98% | 56397 | riw@cisco.com 2.55% | 6 | 3.13% | 44390 | rcallon@juniper.net 2.55% | 6 | 2.24% | 31801 | jari.arkko@piuha.net 2.55% | 6 | 1.92% | 27188 | jnc@mercury.lcs.mit.edu 1.70% | 4 | 2.19% | 31091 | hardie@qualcomm.com 1.70% | 4 | 1.81% | 25608 | dmm@1-4-5.net 1.70% | 4 | 1.80% | 25577 | marcelo@it.uc3m.es 1.70% | 4 | 1.78% | 25303 | bruce.curtis@ndsu.edu 1.70% | 4 | 1.69% | 24030 | oran@cisco.com 1.28% | 3 | 2.11% | 29940 | rw@firstpr.com.au 1.28% | 3 | 1.78% | 25229 | mstenber@cisco.com 1.70% | 4 | 1.29% | 18274 | yakov@juniper.net 1.28% | 3 | 1.31% | 18590 | rogerj@jorgensen.no 0.85% | 2 | 1.38% | 19519 | pesherb@yahoo.com 0.85% | 2 | 0.89% | 12630 | tme@multicasttech.com 0.85% | 2 | 0.88% | 12441 | jefsey@jefsey.com 0.85% | 2 | 0.85% | 12049 | iljitsch@muada.com 0.85% | 2 | 0.72% | 10254 | bortzmeyer@nic.fr 0.85% | 2 | 0.61% | 8644 | andrew@indranet.co.nz 0.85% | 2 | 0.57% | 8152 | rja@extremenetworks.com 0.43% | 1 | 0.52% | 7315 | gvandeve@cisco.com 0.43% | 1 | 0.49% | 6974 | darlewis@cisco.com 0.43% | 1 | 0.48% | 6819 | heinerhummel@aol.com 0.43% | 1 | 0.41% | 5828 | pekkas@netcore.fi 0.43% | 1 | 0.40% | 5706 | andrew.lange@alcatel-lucent.com 0.43% | 1 | 0.39% | 5487 | pds@lugs.com 0.43% | 1 | 0.37% | 5245 | bonaventure@info.ucl.ac.be 0.43% | 1 | 0.35% | 5019 | dogwallah@gmail.com 0.43% | 1 | 0.33% | 4638 | tony.li@tony.li 0.43% | 1 | 0.33% | 4609 | gert@space.net 0.43% | 1 | 0.31% | 4365 | elwynd@dial.pipex.com --------+------+--------+----------+------------------------ 100.00% | 235 |100.00% | 1417894 | Total _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 06 10:46:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZph1-0007Ft-4R; Fri, 06 Apr 2007 10:45:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZph0-0007Fn-89 for ram@iab.org; Fri, 06 Apr 2007 10:45:34 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZpgy-0005iq-1u for ram@iab.org; Fri, 06 Apr 2007 10:45:34 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 84FFE8730A; Fri, 6 Apr 2007 10:45:31 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Weekly posting summary for ram@iab.org Message-Id: <20070406144531.84FFE8730A@mercury.lcs.mit.edu> Date: Fri, 6 Apr 2007 10:45:31 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 1.4 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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: Thomas Narten > I'm hearing from folk that they can't keep up with this list .. > No one benefits if people quit reading messages due to overload. True (and I must confess I can't always read all the posts as carefully as I might like), but at the same time... i) this is a complex topic, and people shouldn't expect that it will be easy to keep up with, and be part of, the debate, without some significant expenditure of effort, and ii) a topic this complex and troubling is going to require a significant amount of interaction to make progress on, and limiting the interaction is going to have a negative effect. If all you were saying is "post sparingly, and use your time at the virtual mike wisely, but keep at it" I'm OK with that, but I didn't think excessive posting was a significant problem on RAM. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 06 11:13:30 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZq6a-0007cX-P3; Fri, 06 Apr 2007 11:12:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZq6Y-0007cR-W6 for ram@iab.org; Fri, 06 Apr 2007 11:11:58 -0400 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZq6X-0006Hk-Ko for ram@iab.org; Fri, 06 Apr 2007 11:11:58 -0400 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.13.8/8.13.8) with ESMTP id l36FBsBF021807; Fri, 6 Apr 2007 08:11:54 -0700 Received: (from dmm@localhost) by m106.maoz.com (8.13.8/8.12.11/Submit) id l36FBoRX021806; Fri, 6 Apr 2007 08:11:50 -0700 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Fri, 6 Apr 2007 08:11:50 -0700 From: David Meyer To: Noel Chiappa Subject: Re: [RAM] Weekly posting summary for ram@iab.org Message-ID: <20070406151150.GA21769@1-4-5.net> References: <20070406144531.84FFE8730A@mercury.lcs.mit.edu> Mime-Version: 1.0 In-Reply-To: <20070406144531.84FFE8730A@mercury.lcs.mit.edu> 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: "No wasted time, we're alive today, Churnin up the past, there's no easier way, Time's been between us, a means to an end, G_d it's good to be here walking together my friend" -- srv, Life By The Drop X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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="===============0901670106==" Errors-To: ram-bounces@iab.org --===============0901670106== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="a8Wt8u1KmwUX3Y2C" Content-Disposition: inline --a8Wt8u1KmwUX3Y2C Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Apr 06, 2007 at 10:45:31AM -0400, Noel Chiappa wrote: > > From: Thomas Narten >=20 > > I'm hearing from folk that they can't keep up with this list .. > > No one benefits if people quit reading messages due to overload. >=20 > True (and I must confess I can't always read all the posts as carefully as > I might like), but at the same time... i) this is a complex topic, and > people shouldn't expect that it will be easy to keep up with, and be part > of, the debate, without some significant expenditure of effort, and ii) a > topic this complex and troubling is going to require a significant amount > of interaction to make progress on, and limiting the interaction is going > to have a negative effect. >=20 > If all you were saying is "post sparingly, and use your time at the virtu= al > mike wisely, but keep at it" I'm OK with that, but I didn't think excessi= ve > posting was a significant problem on RAM. I have to agree with Noel here. We're dealing with a complex set of problems here that have resisted effective solution for *decades* now. Considering that, one would hope there is a lot of discussion. And IMO the S/N has been relatively favorable (especially as compared to most mailing lists). =20 --dmm --a8Wt8u1KmwUX3Y2C Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFGFmM2ORgD1qCZ2KcRAme7AJ9S8XJ00K02z45Xu9BIEhiQ70101ACfRhRH c8fzYg1PXpRMylkJlJTAmuw= =tj2v -----END PGP SIGNATURE----- --a8Wt8u1KmwUX3Y2C-- --===============0901670106== 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 --===============0901670106==-- From ram-bounces@iab.org Fri Apr 06 13:06: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 1HZrrA-0004xS-6G; Fri, 06 Apr 2007 13:04:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HZrr8-0004xI-C4 for ram@iab.org; Fri, 06 Apr 2007 13:04:10 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HZrr7-0001dU-0K for ram@iab.org; Fri, 06 Apr 2007 13:04:10 -0400 Received: from [192.168.0.2] (pool-70-23-225-177.ny325.east.verizon.net [70.23.225.177]) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l36H3kur074460 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 6 Apr 2007 13:03:49 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: <4612A81C.20405@piuha.net> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <08FEEA3E-FE05-4076-81F5-F539653F62A9@lugs.com> <4612A81C.20405@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: Peter Schoenmaker Subject: Re: TE requirements (was: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP)) Date: Fri, 6 Apr 2007 13:03:38 -0400 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Fri, 06 Apr 2007 13:03:50 -0400 (EDT) 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 On Apr 3, 2007, at 3:16 PM, Jari Arkko wrote: > Peter, > >> For the case of multihomed end sites the weighting in the mapping >> lookup should be sufficient for TE. The requirements are fairly >> simple. For the case of TE between ISPs, the TE requirements are >> more >> complicated. Hot potato vs cold potato. Which adjacent AS to >> prefer, >> and which link to an adjacent as to use. > Let me ask for a clarification. When you say that the TE requirements > are simple for end sites, are you saying that from the point of view > of a provider who needs to apply TE to that site? Or from the point > of view of the end-site network manager? What about the mapping > weights -- is a static mapping sufficient, or does it have to be > dynamic? I'm talking from what i perceive as the TE requirements of the end- site network manager. From my view there are two types of multi- homed customers. The simple one where they have one location with connections to multiple providers, the other is where a multi-site customer network connects to multiple providers in multiple locations. The complex multihoming customer actually appears more as an ISP rather than a multihomed customer. I think for the simple multihomed customer the default configuration would be static mapping which should cover most needs. A large benefit of a mapping solution is that it would allow people to develop a dynamic system to meet their needs. peter > > Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 07 07:45:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha9JF-0001vu-Sn; Sat, 07 Apr 2007 07:42:21 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ha9JE-0001vo-IY for ram@iab.org; Sat, 07 Apr 2007 07:42:20 -0400 Received: from smtp7-g19.free.fr ([212.27.42.64]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ha9JD-0006Sy-9k for ram@iab.org; Sat, 07 Apr 2007 07:42:20 -0400 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 560CB17C10; Sat, 7 Apr 2007 13:42:03 +0200 (CEST) X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 07 Apr 2007 13:42:21 +0200 To: David Meyer ,Noel Chiappa From: JFC Morfin Subject: Re: [RAM] Weekly posting summary for ram@iab.org In-Reply-To: <20070406151150.GA21769@1-4-5.net> References: <20070406144531.84FFE8730A@mercury.lcs.mit.edu> <20070406151150.GA21769@1-4-5.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-Id: <20070407114203.560CB17C10@smtp7-g19.free.fr> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 When there was a similar attempt to consider the mail of the future, James Seng had consolidated the different positions and evolutions in a very effective Wiki. Maybe someone or some people could be interested in such a task? It would be a blessing. jfc At 17:11 06/04/2007, David Meyer wrote: >On Fri, Apr 06, 2007 at 10:45:31AM -0400, Noel Chiappa wrote: > > If all you were saying is "post sparingly, and use your time at the virtual > > mike wisely, but keep at it" I'm OK with that, but I didn't think excessive > > posting was a significant problem on RAM. > > I have to agree with Noel here. We're dealing with a > complex set of problems here that have resisted effective > solution for *decades* now. Considering that, one would > hope there is a lot of discussion. And IMO the S/N has > been relatively favorable (especially as compared to most > mailing lists). > > --dmm _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 07 14:58:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaG40-0002bm-3L; Sat, 07 Apr 2007 14:55:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaG3z-0002bh-91 for ram@iab.org; Sat, 07 Apr 2007 14:55:03 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaG3v-0002eM-Tm for ram@iab.org; Sat, 07 Apr 2007 14:55:03 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 07 Apr 2007 11:54:59 -0700 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 l37IsuXW031815; Sat, 7 Apr 2007 11:54:56 -0700 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 l37Ispwn006038; Sat, 7 Apr 2007 18:54:55 GMT 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, 7 Apr 2007 11:54:51 -0700 Received: from [192.168.0.100] ([10.21.145.66]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 11:54:50 -0700 In-Reply-To: <20070407114203.560CB17C10@smtp7-g19.free.fr> References: <20070406144531.84FFE8730A@mercury.lcs.mit.edu> <20070406151150.GA21769@1-4-5.net> <20070407114203.560CB17C10@smtp7-g19.free.fr> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <74C0E5CD-E77D-4BC5-9E99-4D3FDADC7942@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Weekly posting summary for ram@iab.org Date: Sat, 7 Apr 2007 11:54:48 -0700 To: JFC Morfin X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Apr 2007 18:54:50.0984 (UTC) FILETIME=[38BB9E80:01C77946] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=550; t=1175972096; x=1176836096; 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:=20Re=3A=20[RAM]=20Weekly=20posting=20summary=20for=20ram@iab.or g |Sender:=20; bh=Gu5+tJvN3theBYduB5RsXI8ko4Ak+n8dSppMJdJqK0Q=; b=MyzuAFq+d+o0eWk068SAibvBMpT9iv8PlG9eyPE/+F7U8wzZ5IjEqHobYJBOEa1yMBmRTRW6 00bgNKHiUfl5IByljJRFAIqKVq+oEAJoYXckYGl7bLJI7CaGJeOdOnfZ; 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: cf4fa59384e76e63313391b70cd0dd25 Cc: Noel Chiappa , 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 Apr 7, 2007, at 4:42 AM, JFC Morfin wrote: > When there was a similar attempt to consider the mail of the > future, James Seng had consolidated the different positions and > evolutions in a very effective Wiki. Maybe someone or some people > could be interested in such a task? It would be a blessing. The RRG has started such a page already. It can be found here: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup Contributions are welcome. As always, professional behavior is expected. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 07 16:02:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaH45-0000u7-W1; Sat, 07 Apr 2007 15:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaH44-0000tu-JN for ram@iab.org; Sat, 07 Apr 2007 15:59:12 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaH43-0004lw-0A for ram@iab.org; Sat, 07 Apr 2007 15:59:12 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 150EFC01E1; Sat, 7 Apr 2007 21:59:08 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp03.uc3m.es (Postfix) with ESMTP id C5D59C016F; Sat, 7 Apr 2007 21:59:05 +0200 (CEST) In-Reply-To: <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 7 Apr 2007 17:58:08 +0200 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac 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 sorry for the delayed reply... El 01/04/2007, a las 1:18, Tony Li escribi=F3: >>> > >>> I'm not yet convinced that this is really a requirement. Consider =20= >>> what you're asking: the ability to TE on a per-site basis, given=20 >>> that traffic is already assigned to PA prefixes. Typically in the=20= >>> past, ISPs have wanted to do TE within another providers prefix,=20 >>> and thus we have more specifics. This is incredibly important for=20= >>> managing peering ratios and the like. However, applying TE on=20 >>> multi-homed PI sites seems like it would be much less important=20 >>> requirement. >> >> but this seems to be the only difference from the operator=20 >> perspective, between a PI-BGP based multihoming solution and a=20 >> multihoming solution based on PA and an host based mechanism like HIP=20= >> or shim. > > > Not necessarily. Consider an ITR/ETR co-located with a PE router. =20 > That's very interesting from an operator perspective as they can then=20= > effectively change locators for a site without site intervention. > i am not sure how this would work... are you considering the case of a multihomed site connected to two or=20 more different ISPs? because if this is the case, it seems a bit strange to me that a end=20 site will allow one of its isps to select the other ISP to send traffic=20= (by selecting the other ISP prefix/locator) i mean, i think that allowing a ISP to select the other ISP locator may=20= not be such a good idea and seems a bit off limits of what a ISP should=20= be able to control on its client's equipment... am i missing something? > >> since the ISPs claim that there is some TE functionalities missing,=20= >> it zould be important to understand what are those so ze can actually=20= >> provide those... > > > I agree. Moreover, it's important that we confirm that the features=20= > that we are providing are those that are beneficial. > agree but it seems that so far, we haven't managed to get the operational=20 community to describe what exact TE capabilities they need (except from=20= J. Schiller initial effort a year ago, but that didn't end up=20 documented in a draft AFAICT...) regards, marcelo > Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 07 16:02:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaH45-0000u2-Px; Sat, 07 Apr 2007 15:59:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaH44-0000tr-Ih for ram@iab.org; Sat, 07 Apr 2007 15:59:12 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaH43-0004ln-0A for ram@iab.org; Sat, 07 Apr 2007 15:59:12 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8776EC01D1; Sat, 7 Apr 2007 21:59:05 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp03.uc3m.es (Postfix) with ESMTP id 55849C016F; Sat, 7 Apr 2007 21:59:05 +0200 (CEST) In-Reply-To: <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Incremental Deployment of LISP Date: Sat, 7 Apr 2007 18:03:16 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) 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 El 02/04/2007, a las 8:24, Dino Farinacci escribi=F3: >> I think this heavily depends on what scenario you are considering >> >> in LISP 1 doesn't matter, since both identifiers and locators are=20 >> routable >> So, if you do have an alternative locator for the identifier, then=20 >> tunnel, else, forward directly >> >> similar in LISP 1.5 >> >> In LISP 2 and 3 the issue you are considering needs to be considered=20= >> imho >> >> probably it will induce additional latency, since you probably want=20= >> to check if the dest address is an identifier. >> >> in LISP 3 it depends wheter you are using the push or pull model >> >> if you have all the identifier to locator database available, then=20 >> you can check on it to verify if the destination is a identifier and=20= >> which are the locators >> >> if you don't have it, well, then you need to make a query and find=20 >> out, which will take additional delay > > You are right non Marcelo. I think taking the high-road by doing a=20 > LISP-push model gives you the best of all worlds. by push model, we are talking about destributing the ID to locator=20 mapping database to all LISP routers? are you thinking in using a protocol for that distribution, like BGP=20 for instance? There have been a few proposals on this area before, which were very=20 interesting imho, but i guess some people though they were too complex regards, marcelo > We still can incrementally deploy tunneling and by augmenting=20 > LISP-CAs and LISP-peering routers we can get EID-to-RLOC integrity,=20 > DOS-protection, and non-routable IDs. > > Mark Handley and I are working on a proposal. Give us some time to get=20= > it written down. > > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 07 16:53:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHtw-0005B1-K5; Sat, 07 Apr 2007 16:52:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaHtv-000537-C0 for ram@iab.org; Sat, 07 Apr 2007 16:52:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaHtu-0005RY-2V for ram@iab.org; Sat, 07 Apr 2007 16:52:47 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 07 Apr 2007 13:52:45 -0700 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 l37KqjrG008397; Sat, 7 Apr 2007 13:52:45 -0700 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 l37KqiMF019055; Sat, 7 Apr 2007 20:52:45 GMT 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); Sat, 7 Apr 2007 13:52:44 -0700 Received: from [192.168.0.100] ([10.21.145.66]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 13:52:43 -0700 In-Reply-To: <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sat, 7 Apr 2007 13:52:41 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 07 Apr 2007 20:52:43.0838 (UTC) FILETIME=[B07B7DE0:01C77956] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1109; t=1175979165; x=1176843165; c=relaxed/simple; s=sjdkim2002; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=NPQG2Y+U1JaIfAM8GG+PHEY/LM+b9PSECYQnjXhlokc=; b=1LkYCMr6f8z42Ley0bl0S37W7Iwh7NQDzIGqaF+QYUKnxzsps1ul2v4srFoIFGGYSPlK5FA4 3a2nkTe2xJgMt7f6WEjxcY+/IB+CmKfg61kGu0HeE+6KQDaZURF7MBwN; Authentication-Results: sj-dkim-2; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim2002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 >> Consider an ITR/ETR co-located with a PE router. That's very >> interesting from an operator perspective as they can then >> effectively change locators for a site without site intervention. > > i am not sure how this would work... > > are you considering the case of a multihomed site connected to two > or more different ISPs? Nope, it's interesting even for a singly homed site. > because if this is the case, it seems a bit strange to me that a > end site will allow one of its isps to select the other ISP to send > traffic (by selecting the other ISP prefix/locator) > > i mean, i think that allowing a ISP to select the other ISP locator > may not be such a good idea and seems a bit off limits of what a > ISP should be able to control on its client's equipment... Many sites want to outsource as much as possible. Letting/asking/ paying for their ISP to manage something for the site is common. Consider PPVPNs, for example. Of course, it is optional. Having the ITR be the CE box (or one of many) is also an viable alternative. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 07 22:40: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 1HaNHj-00059m-AP; Sat, 07 Apr 2007 22:37:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaNHi-00059Z-0F for ram@iab.org; Sat, 07 Apr 2007 22:37:42 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaNHg-0000yN-Ko for ram@iab.org; Sat, 07 Apr 2007 22:37:41 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 07 Apr 2007 19:37:32 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l382bVXf016625; Sat, 7 Apr 2007 19:37:31 -0700 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 l382bQEi005216; Sun, 8 Apr 2007 02:37:27 GMT 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); Sat, 7 Apr 2007 19:37:26 -0700 Received: from [192.168.0.4] ([10.21.121.239]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 7 Apr 2007 19:37:26 -0700 In-Reply-To: <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> 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] Incremental Deployment of LISP Date: Sat, 7 Apr 2007 19:37:32 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Apr 2007 02:37:26.0479 (UTC) FILETIME=[D84C0DF0:01C77986] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=908; t=1175999851; x=1176863851; 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]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=CY5a+m6jPF6DFVfITBL1M3JiCajTRb6nreRrvdUe66Y=; b=HlfKK7K37ZF4WH1xbS/xhIln+70e8ImU0jxsHUhb7TTP/WjPYmO9d8I6OKIas3stdINxfYIx KSnvqKxt6SrzvXi4O03cNVvMiB1tt7hvnzv5VZScDqXRQZX2TIgRrIuf; 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: 93238566e09e6e262849b4f805833007 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 >> You are right non Marcelo. I think taking the high-road by doing a >> LISP-push model gives you the best of all worlds. > > by push model, we are talking about destributing the ID to locator > mapping database to all LISP routers? I would say all high-level routers and not to every LISP ITR (or ETR). > are you thinking in using a protocol for that distribution, like > BGP for instance? A new protocol more optimized perhaps for flooding that has authentication built-in. > There have been a few proposals on this area before, which were > very interesting imho, but i guess some people though they were too > complex We can start simple. This doesn't need to be complex and if we keep policy out of it ;-) we can keep it easier. Please note, this protocol would be there to distribute EID-RLOC mappings and not the reachability status of the RLOCs. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 08 04:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8x-0003ID-Mb; Sun, 08 Apr 2007 04:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8w-0003FI-IM for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaT8t-0001lw-Fw for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5F1B2117E5A; Sun, 8 Apr 2007 10:52:58 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp02.uc3m.es (Postfix) with ESMTP id 0593C117E38; Sun, 8 Apr 2007 10:52:57 +0200 (CEST) In-Reply-To: References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1902afc60b811e5cc558d71ca3895fdd@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 8 Apr 2007 10:41:06 +0200 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 El 07/04/2007, a las 22:52, Tony Li escribi=F3: > >>> Consider an ITR/ETR co-located with a PE router. That's very=20 >>> interesting from an operator perspective as they can then=20 >>> effectively change locators for a site without site intervention. >> >> i am not sure how this would work... >> >> are you considering the case of a multihomed site connected to two or=20= >> more different ISPs? > > > Nope, it's interesting even for a singly homed site. > so, a single homed site with multiple locators? what would be the=20 motivation for that? do you think this would be a common case? > >> because if this is the case, it seems a bit strange to me that a end=20= >> site will allow one of its isps to select the other ISP to send=20 >> traffic (by selecting the other ISP prefix/locator) >> >> i mean, i think that allowing a ISP to select the other ISP locator=20= >> may not be such a good idea and seems a bit off limits of what a ISP=20= >> should be able to control on its client's equipment... > > > Many sites want to outsource as much as possible. =20 > Letting/asking/paying for their ISP to manage something for the site=20= > is common. right, but as long there is no conflict of interests. letting one ISP=20 to forward the traffic through the alternative ISP could generate such=20= conflict of interests... I guess it depends on the pricing structure. I=20= mean, if the end siFrom ram-bounces@iab.org Sun Apr 08 04:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8x-0003ID-Mb; Sun, 08 Apr 2007 04:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8w-0003FI-IM for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaT8t-0001lw-Fw for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5F1B2117E5A; Sun, 8 Apr 2007 10:52:58 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp02.uc3m.es (Postfix) with ESMTP id 0593C117E38; Sun, 8 Apr 2007 10:52:57 +0200 (CEST) In-Reply-To: References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <1902afc60b811e5cc558d71ca3895fdd@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 8 Apr 2007 10:41:06 +0200 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 El 07/04/2007, a las 22:52, Tony Li escribi=F3: > >>> Consider an ITR/ETR co-located with a PE router. That's very=20 >>> interesting from an operator perspective as they can then=20 >>> effectively change locators for a site without site intervention. >> >> i am not sure how this would work... >> >> are you considering the case of a multihomed site connected to two or=20= >> more different ISPs? > > > Nope, it's interesting even for a singly homed site. > so, a single homed site with multiple locators? what would be the=20 motivation for that? do you think this would be a common case? > >> because if this is the case, it seems a bit strange to me that a end=20= >> site will allow one of its isps to select the other ISP to send=20 >> traffic (by selecting the other ISP prefix/locator) >> >> i mean, i think that allowing a ISP to select the other ISP locator=20= >> may not be such a good idea and seems a bit off limits of what a ISP=20= >> should be able to control on its client's equipment... > > > Many sites want to outsource as much as possible. =20 > Letting/asking/paying for their ISP to manage something for the site=20= > is common. right, but as long there is no conflict of interests. letting one ISP=20 to forward the traffic through the alternative ISP could generate such=20= conflict of interests... I guess it depends on the pricing structure. I=20= mean, if the end site pays its isp by load, then i guess that maybe the=20= conflict of interests could be avoided, since the incentives seem to=20 lead isps to attract traffic, otoh, if the end site pays flat rate, i=20 can see an incentive for the isp to divert as much traffic as possible=20= to the alternative isp. regards, marcelo > Consider PPVPNs, for example. > > Of course, it is optional. Having the ITR be the CE box (or one of=20 > many) is also an viable alternative. > > Tony > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 08 04:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8x-0003I8-Eq; Sun, 08 Apr 2007 04:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8w-0003FL-Ie for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaT8t-0001lx-Fx for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C3115117E38; Sun, 8 Apr 2007 10:52:58 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp02.uc3m.es (Postfix) with ESMTP id 61D36117F6D; Sun, 8 Apr 2007 10:52:58 +0200 (CEST) In-Reply-To: References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <816668963e0ee48143c31b9006c551d0@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Sun, 8 Apr 2007 10:50:51 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 El 08/04/2007, a las 4:37, Dino Farinacci escribi=F3: >>> You are right non Marcelo. I think taking the high-road by doing a=20= >>> LISP-push model gives you the best of all worlds. >> >> by push model, we are talking about destributing the ID to locator=20 >> mapping database to all LISP routers? > > I would say all high-level routers i am not sure what do you mean by high level router... could you expand? > and not to every LISP ITR (or ETR). > but the ITR are the ones than need the information (hence the ones that=20= should have it), right? Of course, in addition, routers making TE would also benefit from it,=20 so it makes sense to pass it to them also (but they are ITRs after all,=20= right?) >> are you thinking in using a protocol for that distribution, like BGP=20= >> for instance? > > A new protocol more optimized perhaps for flooding that has=20 > authentication built-in. > what is the motivation for a newte pays its isp by load, then i guess that maybe the=20= conflict of interests could be avoided, since the incentives seem to=20 lead isps to attract traffic, otoh, if the end site pays flat rate, i=20 can see an incentive for the isp to divert as much traffic as possible=20= to the alternative isp. regards, marcelo > Consider PPVPNs, for example. > > Of course, it is optional. Having the ITR be the CE box (or one of=20 > many) is also an viable alternative. > > Tony > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 08 04:56:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8x-0003I8-Eq; Sun, 08 Apr 2007 04:53:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaT8w-0003FL-Ie for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaT8t-0001lx-Fx for ram@iab.org; Sun, 08 Apr 2007 04:53:02 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id C3115117E38; Sun, 8 Apr 2007 10:52:58 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp02.uc3m.es (Postfix) with ESMTP id 61D36117F6D; Sun, 8 Apr 2007 10:52:58 +0200 (CEST) In-Reply-To: References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <816668963e0ee48143c31b9006c551d0@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Sun, 8 Apr 2007 10:50:51 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 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 El 08/04/2007, a las 4:37, Dino Farinacci escribi=F3: >>> You are right non Marcelo. I think taking the high-road by doing a=20= >>> LISP-push model gives you the best of all worlds. >> >> by push model, we are talking about destributing the ID to locator=20 >> mapping database to all LISP routers? > > I would say all high-level routers i am not sure what do you mean by high level router... could you expand? > and not to every LISP ITR (or ETR). > but the ITR are the ones than need the information (hence the ones that=20= should have it), right? Of course, in addition, routers making TE would also benefit from it,=20 so it makes sense to pass it to them also (but they are ITRs after all,=20= right?) >> are you thinking in using a protocol for that distribution, like BGP=20= >> for instance? > > A new protocol more optimized perhaps for flooding that has=20 > authentication built-in. > what is the motivation for a new protocol? i mean, BGP does seem to provide what is needed, and it is well known=20 by the community do you think that BGP is lacking some of the required capabilities? note that for globally distributing the ID to locator mapping=20 information, you would just need to enable another instance of BGP with=20= maybe some extensions, that would carry the id to loc mapping to all=20 the routers running this new instance. I think that from a deployment=20 perspective, this is much better than designing a new protocol, since=20 it would only require configure existent routers (maybe some software=20 patch) but not deploying a new protocol (I think this would go along=20 with the general LISP policy of minor changes rather than new=20 protocols, doesn't it?) >> There have been a few proposals on this area before, which were very=20= >> interesting imho, but i guess some people though they were too=20 >> complex > > We can start simple. This doesn't need to be complex and if we keep=20 > policy out of it ;-) we can keep it easier but probably the complex part of policy is to provide enough=20 information and flexibility to allow for local configurations, so this=20= needs to be build in the protocol from scratch, just as BGP has it. > . Please note, this protocol would be there to distribute EID-RLOC=20 > mappings and not the reachability status of the RLOCs. > of course, fully agree > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram protocol? i mean, BGP does seem to provide what is needed, and it is well known=20 by the community do you think that BGP is lacking some of the required capabilities? note that for globally distributing the ID to locator mapping=20 information, you would just need to enable another instance of BGP with=20= maybe some extensions, that would carry the id to loc mapping to all=20 the routers running this new instance. I think that from a deployment=20 perspective, this is much better than designing a new protocol, since=20 it would only require configure existent routers (maybe some software=20 patch) but not deploying a new protocol (I think this would go along=20 with the general LISP policy of minor changes rather than new=20 protocols, doesn't it?) >> There have been a few proposals on this area before, which were very=20= >> interesting imho, but i guess some people though they were too=20 >> complex > > We can start simple. This doesn't need to be complex and if we keep=20 > policy out of it ;-) we can keep it easier but probably the complex part of policy is to provide enough=20 information and flexibility to allow for local configurations, so this=20= needs to be build in the protocol from scratch, just as BGP has it. > . Please note, this protocol would be there to distribute EID-RLOC=20 > mappings and not the reachability status of the RLOCs. > of course, fully agree > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 08 12:07:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaZs2-00045m-6x; Sun, 08 Apr 2007 12:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HaZs1-00045e-OH for ram@iab.org; Sun, 08 Apr 2007 12:04:01 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HaZrz-0003e4-Di for ram@iab.org; Sun, 08 Apr 2007 12:04:01 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 08 Apr 2007 09:03:59 -0700 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 l38G3wTs000635; Sun, 8 Apr 2007 09:03:58 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l38G3sZT003297; Sun, 8 Apr 2007 16:03:54 GMT 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); Sun, 8 Apr 2007 09:03:54 -0700 Received: from [192.168.0.100] ([10.21.116.27]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 09:03:53 -0700 In-Reply-To: <1902afc60b811e5cc558d71ca3895fdd@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> <1902afc60b811e5cc558d71ca3895fdd@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <25E25983-CEFD-4B0A-B097-F2F6C513F0E2@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 8 Apr 2007 09:03:48 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Apr 2007 16:03:53.0532 (UTC) FILETIME=[813A67C0:01C779F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1698; t=1176048238; x=1176912238; c=relaxed/simple; s=sjdkim3002; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=ej6PDFxVm2nS+9/F5ijZQeZd9qRLv+VymxaoAEffxRM=; b=vRaZbZbOkOTDSAHs4ZY6I8l53aWWkVA3PnngfNlIK7K3C47s2HyXo3n/hnzGXglJgKhB/1OM Yy0MfotKhZYQ+1qOi6C9xPT8/bQpSv2/60oykWWvLjlbDYl1f6zh6DeH; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 >>>> Consider an ITR/ETR co-located with a PE router. That's very >>>> interesting from an operator perspective as they can then >>>> effectively change locators for a site without site intervention. >>> >>> are you considering the case of a multihomed site connected to >>> two or more different ISPs? >> >> Nope, it's interesting even for a singly homed site. > > so, a single homed site with multiple locators? what would be the > motivation for that? do you think this would be a common case? No, a single locator is still interesting. There are numerous cases where, as an ISP grows, they would like to renumber a customer and can't today. Typical examples are ISPs that did initial address allocations without regard to future deployment of IGP areas, and ISPs that acquired other, geographically overlapping ISPs. A Loc/ID split helps the site have provider independence, and it also helps the ISP with internal aggregation. > right, but as long there is no conflict of interests. letting one > ISP to forward the traffic through the alternative ISP could > generate such conflict of interests... I guess it depends on the > pricing structure. I mean, if the end site pays its isp by load, > then i guess that maybe the conflict of interests could be avoided, > since the incentives seem to lead isps to attract traffic, otoh, if > the end site pays flat rate, i can see an incentive for the isp to > divert as much traffic as possible to the alternative isp. You mean an ISP might use traffic engineering to optimize its situation? I'm shocked, shocked that you would suggest such a thing! ;-) ;-) ;-) Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 08 14:20:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Habxr-0001Az-4W; Sun, 08 Apr 2007 14:18:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Habxp-0001Au-VT for ram@iab.org; Sun, 08 Apr 2007 14:18:09 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Habxo-0000j2-Cm for ram@iab.org; Sun, 08 Apr 2007 14:18:09 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 0B49CC01B3; Sun, 8 Apr 2007 20:18:07 +0200 (CEST) Received: from [163.117.203.205] (unknown [163.117.203.205]) by smtp03.uc3m.es (Postfix) with ESMTP id C4C81C0060; Sun, 8 Apr 2007 20:18:04 +0200 (CEST) In-Reply-To: <25E25983-CEFD-4B0A-B097-F2F6C513F0E2@cisco.com> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> <1902afc60b811e5cc558d71ca3895fdd@it.uc3m.es> <25E25983-CEFD-4B0A-B097-F2F6C513F0E2@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <30e9282ccf9f2f8e012501114b76bdb5@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 8 Apr 2007 20:18:18 +0200 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 El 08/04/2007, a las 18:03, Tony Li escribi=F3: > >>>>> Consider an ITR/ETR co-located with a PE router. That's very=20 >>>>> interesting from an operator perspective as they can then=20 >>>>> effectively change locators for a site without site intervention. >>>> >>>> are you considering the case of a multihomed site connected to two=20= >>>> or more different ISPs? >>> >>> Nope, it's interesting even for a singly homed site. >> >> so, a single homed site with multiple locators? what would be the=20 >> motivation for that? do you think this would be a common case? > > No, a single locator is still interesting. There are numerous cases=20= > where, as an ISP grows, they would like to renumber a customer and=20 > can't today. Typical examples are ISPs that did initial address=20 > allocations without regard to future deployment of IGP areas, and ISPs=20= > that acquired other, geographically overlapping ISPs. > > A Loc/ID split helps the site have provider independence, and it also=20= > helps the ISP with internal aggregation. > I see what you mean and it makes sense to me but a couple of comments: i) this is not really related to TE, right?=20 (or at least to inter domain TE) ii) you are assuming provider=20 independent identifiers? >> right, but as long there is no conflict of interests. letting one ISP=20= >> to forward the traffic through the alternative ISP could generate=20 >> such conflict of interests... I guess it depends on the pricing=20 >> structure. I mean, if the end site pays its isp by load, then i guess=20= >> that maybe the conflict of interests could be avoided, since the=20 >> incentives seem to lead isps to attract traffic, otoh, if the end=20 >> site pays flat rate, i can see an incentive for the isp to divert as=20= >> much traffic as possible to the alternative isp. > > You mean an ISP might use traffic engineering to optimize its=20 > situation? I'm shocked, shocked that you would suggest such a thing! =20= > ;-) ;-) ;-) :-) of course the ISP may want to do that what i would be surprised is that the customer would allow it... i=20 mean, the client does have to let ISP1 know about ISP2 and its prefix,=20= in order to let ISP1 to divert the traffic through ISP2, (this would=20 imply for someone to configure both prefixes in the same box, right?)=20 and this doesn't makes sense to me so far. Also you could end up in a strange/unstable situation where ISP1 push=20 all the traffic to ISP2 and ISP2 pushes the traffic to ISP1, in order=20 to. So summarizing, i do see a benefit w.r.t. to PI to allow a single box=20 to contain all the PA locator prefix information and even allowing the=20= ISP to manage that box, so that intra ISP renumbering events are=20 transparent to the customer. Still i don't see clear that allowing the ISP to manage that box in a=20 multihoming scenario with multiple ISPs in order to perform TE makes=20 sense from the client p.o.v. Regards, marcelo > > Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 08 18:30:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HafqB-0003bp-3J; Sun, 08 Apr 2007 18:26:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HafqA-0003bk-1E for ram@iab.org; Sun, 08 Apr 2007 18:26:30 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hafq6-0008Di-JX for ram@iab.org; Sun, 08 Apr 2007 18:26:30 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 08 Apr 2007 15:26:14 -0700 Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l38MQDFa010795; Sun, 8 Apr 2007 15:26:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l38MQBA8001738; Sun, 8 Apr 2007 22:26:11 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 15:26:11 -0700 Received: from [192.168.0.100] ([10.21.116.27]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 8 Apr 2007 15:26:10 -0700 In-Reply-To: <30e9282ccf9f2f8e012501114b76bdb5@it.uc3m.es> References: <20070325212832.95633.qmail@web58704.mail.re1.yahoo.com> <53C538FB-B64B-4215-A733-65AEECA399F5@cisco.com> <8a3d633a8136a765320d75ae65cc18b8@it.uc3m.es> <1C542B74-DA89-4C5E-8CB5-811DC8EC6543@cisco.com> <05cffde9b69d9e97bfb75e348e6cfd9b@it.uc3m.es> <65057F30-3D24-4D18-906D-7B329FDE34AD@cisco.com> <3365ce342b5f1bba84c33eaa9debaa20@it.uc3m.es> <900FA81F-EC15-480B-9138-090CF8E2435C@tony.li> <20070331211753.yrjw6vdpmzkco88c@webcartero01.uc3m.es> <4FC4F032-5B75-4053-9059-9466FAF603B0@cisco.com> <1f029bd355f3dbdd0f3e31b00943539d@it.uc3m.es> <1902afc60b811e5cc558d71ca3895fdd@it.uc3m.es> <25E25983-CEFD-4B0A-B097-F2F6C513F0E2@cisco.com> <30e9282ccf9f2f8e012501114b76bdb5@it.uc3m.es> 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 8 Apr 2007 15:26:11 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 08 Apr 2007 22:26:10.0686 (UTC) FILETIME=[E8D659E0:01C77A2C] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2045; t=1176071173; x=1176935173; 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:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=XCd/SPRqXLeMjxBFu25XSw5sXd3ufH+Y98WU9741wvI=; b=k3kexHlBv+OxWl6OfBEmUlUyUB0lRUtMzF7IBo25czpf5/BLdofccEPi8JfoJKFQ3a+pzNME RgtPtBJ1LKzLj/T6Z6FIN2Nj+C+O1CbGYCFcDhW+YCvFtHldEW+Trky6; 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: 8b431ad66d60be2d47c7bfeb879db82c 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 a couple of comments: i) this is not really related to TE, > right? (or at least to inter domain TE) ii) you are assuming > provider independent identifiers? Correct, this has nothing to do with TE. Yes, this is assuming that identifiers are provider independent. Identifiers that were provider dependent are not useful in the least. > what i would be surprised is that the customer would allow it... i > mean, the client does have to let ISP1 know about ISP2 and its > prefix, in order to let ISP1 to divert the traffic through ISP2, > (this would imply for someone to configure both prefixes in the > same box, right?) and this doesn't makes sense to me so far. That would assume that ISP1 was intentionally diverting the traffic. Any such action would be visible on the other side of the net. All it would take would be a looking-glass type mechanism to make this plainly visible. Note that this situation already exists today. All that ISP1 has to do is to AS prepend the customer's PI prefix to divert traffic. Thus, either (a) the looking glass check stops the ISP from being dishonest or (b) he's not such an Evil Greedy Bastard after all. ;-) > Also you could end up in a strange/unstable situation where ISP1 > push all the traffic to ISP2 and ISP2 pushes the traffic to ISP1, > in order to. Kinda like AS prepend wars? > So summarizing, i do see a benefit w.r.t. to PI to allow a single > box to contain all the PA locator prefix information and even > allowing the ISP to manage that box, so that intra ISP renumbering > events are transparent to the customer. > > Still i don't see clear that allowing the ISP to manage that box in > a multihoming scenario with multiple ISPs in order to perform TE > makes sense from the client p.o.v. Again, the enterprise is strongly motivated to outsource, if possible. As discussed, there are ample checks and balances that would curb any ungentlemanly behavior. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 04:57:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hapdu-0007tB-QS; Mon, 09 Apr 2007 04:54:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hapdt-0007sj-C5 for ram@iab.org; Mon, 09 Apr 2007 04:54:29 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hapdq-0003AZ-BV for ram@iab.org; Mon, 09 Apr 2007 04:54:29 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id A964D1790FD; Mon, 9 Apr 2007 10:52:38 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id AB86D1799DD; Mon, 9 Apr 2007 10:44:38 +0200 (CEST) In-Reply-To: <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <460FE3D6.3040300@cisco.com> <03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org> <461124DB.7010106@cisco.com> <42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org> <46112D10.8010201@cisco.com> <6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Mon, 9 Apr 2007 10:44:54 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) 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 El 02/04/2007, a las 19:22, Dino Farinacci escribi=F3: >> On Apr 2, 2007, at 9:19 AM, Eliot Lear wrote: >>>> [latency] >>> Because we shouldn't engineer delay into the system, >> >> There are already numerous delays engineered into the system. > > David, let me try this to see how Eliot will react. > > Eliot, (like Fred Templin's idea), what if the host pointed it's DNS=20= > server address to a router, say the ITR router. > > So when the host does a DNS lookup, the router intercepts it (not=20 > really intercepts it because the UDP packet is addressed to the=20 > router), sends it on but also adds a request record for say a RLOC RR. this basically means that: - The router that will forward the packet should also be configured as=20= the DNS server for those hosts that use such router to send packets to=20= a given destination (i.e. the default router is also the DNS server)=20 (this has some difficulties, because you would need to configure the=20 DNS servers to different hosts depending on the default router they=20 use.. in addition, more complexity will arise when you want to support=20= fault tolerance when the default router fails) - The router also needs a DNS alg, to interpret the DNS query sent by=20 the host and create the additional DNS query to ask for the RLOC RR right? regards, marcelo > The ITR will have to make the request come from the ITR's source=20 > address so the reply returned can get the RLOC RR stored in the=20 > EID-to-RLOC mapping cache by the ITR. Then the ITR can return the A=20 > record reply to the host. > > All this happens before the first TCP SYN is sent by the host. > > There is increased latency, but the host doesn't really know any=20 > differently. > > So question to beg is will IT managers feel comfortable pointing DNS=20= > server addresses to this map-n-encap routers. > > 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 Mon Apr 09 08:08:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hasdc-0005pH-2L; Mon, 09 Apr 2007 08:06:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hasda-0005p5-34 for ram@iab.org; Mon, 09 Apr 2007 08:06:22 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HasdW-0000LJ-2T for ram@iab.org; Mon, 09 Apr 2007 08:06:22 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 5B8DB59E5D; Mon, 9 Apr 2007 22:06:06 +1000 (EST) Message-ID: <461A2C23.9060606@firstpr.com.au> Date: Mon, 09 Apr 2007 22:05:55 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP etc. is not the only path to scalable routing References: <20070404122620.1FF6586AF1@mercury.lcs.mit.edu> In-Reply-To: <20070404122620.1FF6586AF1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Noel Chiappa wrote: > I am reliably informed (i.e. by someone who builds them > for a living) that the vast majority (I don't recall the > specific number, but it's on the order of 75% or so) of > the gates (and heat/power) in contemporary large routers > are consumed by the forwarding, and in particular things > like access controls. The RIB and/or FIB are not the issue. Routers are called upon to do many things, so there are complex requirements for classifying packets which are best handled with TCAM (Ternary Content Addressable Memory) or some other general-purpose system which can analyze any and all aspects of various types of packet, of which IPv4 or IPv6 are only two types. With transit routers, I understand that none of this sophistication is required for handling the main Internet traffic. The only task for the forwarding system of each interface (once the packet checks OK and its TTL is updated and found to be > 0) is to decide which interface to forward the packet to, or to drop it. Multihomed border routers may need to use all sorts of fancy techniques for packets addressed to local prefixes, but for outgoing packets (addressed to the prefixes outside those of the organisation) I understand that the task is the same as just described. The problem in routing and addressing is not that there is great complexity in the handling of Internet traffic - it is the number of prefixes which need to be considered, and the fact that the traffic volume requires that this be done very quickly - ideally in a single operation, rather than iterating through a tree-structured set of rules. Without a new design such as what I am suggesting, the current forwarding architectures, which are flexible, expensive and power-hungry, need to be extended linearly to handle the growing number of BGP routes. Broadly speaking, every new advertised prefix requires a new line in TCAM memory in every DFZ router. My proposal is to add a RAM chip which handles the analysis of all the Internet traffic (for a border router, all traffic not addressed to a local prefix). This means that there is no need to dedicate a TCAM line to each BGP prefix. For each local prefix or any range of addresses where TCAM etc. analysis was required, the SRAM would contain a value, such as '1', meaning "Handle this packet with TCAM etc." For IPv4, each SRAM location applies to a /24 - and every /24 with the local prefixes could be flagged in this way. The result will be that no matter how many global BGP prefixes are advertised, no TCAM resources are required for outgoing Internet traffic in a border router, or for the main traffic of a transit router. The SRAM power consumption, size, cost and complexity is small compared to the rest of the router, but it means that the router can handle any number of BGP routes, to /24 granularity. Extending TCAM to match the growth in the number of routes would add incrementally to the already high cost and power consumption of routers. The SRAM approach is a small step in cost, complexity, etc. and makes such extensions to TCAM etc. unnecessary. Border routers of large ISPs and AS end-users may well need a lot of TCAM etc. But that will only be for local prefixes, and not depend on the number of global BGP routes. RW > More CPU and RAM thrust is required for the RIB and BPG traffic RW > .. but CPUs and SRAM/DRAM are commodity devices and are RW > continually getting cheaper and faster - probably outpacing RW > the current growth in the routing table. > No, not really. For one, I am told that it takes a core router > (i.e. one with complete routing table) a significant fraction of > an hour to load the current complete routing table (via BGP) > when it restarts; this clearly indicates poor dynamic response. Perhaps the reloading and propagation of changes within BGP could be optimised by giving priority to shorter prefixes. If each such prefix provides, on average, connectivity to a greater number of actively used IP addresses, then this would enable most of the of connectivity to be established earlier in the reload cycle. There are potential problems in this - for instance it could encourage people to keep advertising large prefixes to "jump the queue", even though they don't have many active IP addresses within that prefix. Since the main proposal currently under consideration is LISP, which requires some major changes to at least some routers, with a new protocol, new headers, new centralised database of mapping information (LISP 1.5+), I think it is worth investigating how BGP could be enhanced, with faster CPUs and more RAM, to cope with the increased number of advertised routes my proposal would allow and encourage. But the system I am proposing is not intended to cope with generally frequent changes in BGP routes - no more than is necessary for coping with outages and the slow development of network topology. There is a paper on a proposed new routing protocol HLP, which might be helpful. I haven't read it yet: http://www.cs.ucl.ac.uk/staff/M.Handley/papers/hlpsigcomm.pdf > And as other people have already mentioned, but this discussion > doesn't seem to be taking on board, the most troubling issue > with routing is not the static situation (i.e. table size when > things are quiet), but the dynamic situation (i.e. how promptly > the routing responds, *and stabilizes*, when there's a topology > change). > > The following presentation might be helpful in terms of making > this point: > > Quaking Tables: The Taiwan Earthquakes and the Internet > Routing Table > http://www.nanog.org/mtg-0702/presentations/underwood.pdf > > The summary on the slide labeled "Timeline (2)" is particularly > instructive. Thanks for pointing me to this paper. I wonder how much of the longer-term instability is not related to the BGP routing system as such, but to operators trying to manually optimize their networks after this major disruption. Many of the prefixes may have been /24s, but these, in general cover only a tiny percentage (0.23%) of advertised space. For instance, on page 10, which is for a North-East American power outage in 2003, 70% of the prefixes affected were /24s. I am not sure that LISP would produce a better result. While there would be a lower proportion of the total routes actually part of the BGP system, all the LISP encapsulated traffic has to be carried by routes. Also, the LISP system, such the ability to communicate with and maintain a central database of EID to Locator mappings, would be disrupted by the failure of routes in the BGP system. So a new layer of complexity and dependence on centralised resources would add a new set of problems when there is a major disruption. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 08:39:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hat8Z-0006Hk-3D; Mon, 09 Apr 2007 08:38:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hat8Y-0006He-0N for ram@iab.org; Mon, 09 Apr 2007 08:38:22 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hat8V-0005O7-JF for ram@iab.org; Mon, 09 Apr 2007 08:38:21 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id EA92159E46; Mon, 9 Apr 2007 22:38:16 +1000 (EST) Message-ID: <461A33AE.7090508@firstpr.com.au> Date: Mon, 09 Apr 2007 22:38:06 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP etc. is not the only path to scalable routing References: DEFANGED[2851]:DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing. " " com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> <46139B56.5000202@zurich.ibm.com> In-Reply-To: <46139B56.5000202@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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 Brian Carpenter wrote: RW > Some careful decisions would need to be made about IPv6, RW > because the current global unicast range involves too many RW > changing bits to map into SRAM. > There's a reason for that. Because of the address shortage, > we have been forced over the last 15 years to use IPv4 space > extremely conservatively, avoiding sparse allocation at all > costs. My impression is that this pressure has been in the last 10 years or so. Whole /8s were allocated to some companies and organisations in the early 1990s, and 12 of them are not even advertised at present. This is visible as a purple '0' in column 4 of the table at the end of: http://www.firstpr.com.au/ip/host-density-per-prefix/ Most of the remainder are lightly used. For instance, 19 of them are advertised as a single /8. I think it is unlikely that these prefixes are heavily populated with actively used IP addresses, if each one is advertised from the one router. Random pings to these prefixes generally result in none or few acknowledgments. > One of the drivers for the choice of 128 bits for > IPv6 (rather than say 64) was to avoid this artificial > pressure for compact allocation. Sparse allocation is much > less annoying for sites, since it's much less likely to > lead to churn in an addressing plan (which is an even bigger > pain point than simple prefix renumbering). But if the flat routing system I am proposing (as David Conrad correctly described it) was in place, then most or all of the long-held assumptions about addressing which underlie what you mention, would no longer apply. With a flat routing system, an organisation can get a prefix of addresses, effectively permanently (PI for AS end-users including in IPv6), to last its needs for new addresses for a year or so. When the end-user or ISP needs more, they can get another prefix. In terms of the DFZ, it doesn't matter that the one large organisation has a few dozen or a thousand or so /24s, even if some or all of them are non-contiguous. I am not suggesting addresses only be assigned in /24s - bigger organisations need more addresses per assignment, but with flat routing they don't need a single large block of space which will last them for a decade or two. Within each AS end-user's network, they only need SRAM-equipped routers for border routers with two or more links to upstream ISPs. The rest of the routing can be handled well by conventional amounts of TCAM etc., unless the local prefixes are so numerous as to stretch the limits of TCAM. This seems unlikely except for all but the biggest AS end-users. Probably our biggest problem is that the global BGP routing table is requiring more and more expensive TCAM, or an equally expensive and complex alternative, for every DFZ router. The SRAM approach solves this problem with a modest design addition for the next generation of DFZ routers. An AS end-user might prefer to receive a single large slab of addresses and to do whatever they like with that over the next decade or two. But having a bunch of smaller prefixes, which are effectively for keeps and which are all routable globally, no matter how they are split (down to a /24 granularity) should be about as easy to manage, although it is not as aesthetically pleasing. Even if an AS end-user had some big slab, such as a /8 - as some do - then if they are going to support multiple sites, each multihomed, this generates a complex set of routing rules in their internal networks anyway. I don't see much practical difference between building a network incrementally, with separate, effectively permanent, smaller pieces of address space - which are all well utilised - than starting with one huge slab and populating it piecemeal. Without a flat routing system, the principle is something like this: Each AS end-user (or ISP) needs to constrain its address utilisation for the next decade or so to either one prefix, or as few prefixes as possible, in order to maximise route aggregation. Because there is no financial cost in getting IP addresses, because the RIRs are so keen to maximise route aggregation, and since an AS end-user is happier with more IP addresses than with less, the pattern has been to hand out slabs of IP address space which are larger rather than smaller. Consequently, most of this space is sparsely used - and with only ~150 million to 300 million (I guess at a maximum) IP addresses on the Net currently in use (~110 million responding to pings), we are widely believed to be close to running out of address space. We are, as long as the current requirement for route aggregation remains. LISP in theory routes around this, but by the time it is implemented widely, most IP addresses will have been assigned and advertised as part of the BGP routing system. LISP 1.0 doesn't achieve anything for reducing the number of BGP routes. LISP 1.5 and above could - but that will require some mechanism for removing large numbers of prefixes from the BGP routing system, relegating them to a second-class service which depends on the LISP infrastructure. I can't see why anyone would agree to their prefixes being downgraded in this way, unless perhaps LISP provided some traffic engineering benefits which are not available on globally routable BGP prefixes. The idea of route aggregation and the feeling of vast space which is easily provided by having a bunch more bits in the addressing scheme, gives IPv6 a heady feeling of endless horizons, for free. In some ways, this is true - for instance each /48 provides 64k user networks, each of which have essentially unlimited numbers of public IP addresses. Assuming each small to medium non-AS end-user gets a /48 - say homes and up to 10,000 person business sites - then I don't agree with: > Or in other words, the IPv6 equivalent of a /24 is a /48 or > even a /56. A /48 has bits 79 to 0 in flux - giving each such user 64K LANs of up to billions of hosts. What my SRAM proposal needs is a more compact handling of the bits 124 to, for instance 92 (a /35 prefix). This will feel really bad to anyone who feels good about vast expanses of address space, for instance on the basis that a single prefix will last an organisation for decades, no matter how much it expands. But that feeling isn't necessary in a flat routing model, because each AS end-user or ISP can easily get more space, non-contiguously, as they need it. One approach is to have SRAM mapping for 2 million /35s. Each /35 provides 8192 /48s. This system would provide for assignment, effectively permanently, of globally routable space, down to /35 prefixes - which is capable of supporting 16 billion /48 user networks. This is Provider Independent space for both ISPs and AS end-users. This space greatly exceeds IPv4s even if we think of a /48 as equivalent to a single IPv4 address. It will also be much more efficiently used than IPv4 space, (thinking again of an IPv6 as equivalent to a single IPv4 IP address) because it can be split into 2 million globally routable PI /35 prefixes, each of which can be used more flexibly than we are used to with the current focus on maximising route aggregation. In this example, the SRAM system would span a /14, with for instance, RIRs typically handing out space in /32s, each of which could be split into 8 separately advertisable /35s. Because there are a quarter million of these /32s to go around, and because each AS end-user or ISP would use one reasonably fully before asking for another, this address space would go a long way. At a later date, a subsequent generation of routers with more memory could cover this /14 and the next one or three /14s, making the total SRAM-handled flat routing space into a /12 or so. These figures all probably sound frighteningly restrictive compared to the /3 which is currently being allocated and assigned. But that space can't be flat routed. It would require vast amounts of TCAM in all DFZ routers if IPv6 is to be widely adopted. If people can forget two decades of thinking about the need for route aggregation, and can imagine that the BGP system - or something to replace or supplement it - can handle the larger number of routes, then I think they will be able to imagine that the IPv6 example I gave is still a vast address space, and that flat routing down to /24 in IPv4 will facilitate a much more effective use of the 3.6 billion IPv4 addresses. - Robin http://tools.ietf.org/html/draft-whittle-sram-ip-forwarding-01 http://www.firstpr.com.au/ip/sram-ip-forwarding/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 10:45:18 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hav6D-0000Fc-8s; Mon, 09 Apr 2007 10:44:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hav6C-0000FV-2X for ram@iab.org; Mon, 09 Apr 2007 10:44:04 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hav6A-0004V4-Sv for ram@iab.org; Mon, 09 Apr 2007 10:44:04 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 6958086AF1; Mon, 9 Apr 2007 10:44:02 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] LISP etc. is not the only path to scalable routing Message-Id: <20070409144402.6958086AF1@mercury.lcs.mit.edu> Date: Mon, 9 Apr 2007 10:44:02 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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: Robin Whittle > Noel Chiappa wrote: >> I am reliably informed .. that the vast majority .. of the gates >> (and heat/power) in contemporary large routers are consumed by the >> forwarding, and in particular things like access controls. >> The RIB and/or FIB are not the issue. > With transit routers, I understand that none of this sophistication > is required for handling the main Internet traffic. My original message specified "large routers"; i.e. core routers. I'm not sure why core routers need these features, but ISP's apparently use (and are willing to pay for) them. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 10:58:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavKJ-0000NP-TH; Mon, 09 Apr 2007 10:58:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HavKI-0000L6-Sp for ram@iab.org; Mon, 09 Apr 2007 10:58:38 -0400 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 1HavKF-0008Vo-IC for ram@iab.org; Mon, 09 Apr 2007 10:58:38 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l39EwVZN026047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2007 07:58:32 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l39EwVRZ006089; Mon, 9 Apr 2007 09:58:31 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l39EwOmj005832; Mon, 9 Apr 2007 09:58:30 -0500 (CDT) 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); Mon, 9 Apr 2007 07:58:29 -0700 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Mon, 9 Apr 2007 07:58:28 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd6hQqmp5MuOUrCTA2AimRxbfVqCwALfS1A References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> From: "Templin, Fred L" To: "marcelo bagnulo braun" , "Dino Farinacci" X-OriginalArrivalTime: 09 Apr 2007 14:58:29.0752 (UTC) FILETIME=[88E2D780:01C77AB7] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 basically means that: >=20 > - The router that will forward the packet should also be=20 > configured as=20 > the DNS server for those hosts that use such router to send=20 > packets to=20 > a given destination (i.e. the default router is also the DNS server) That's right. =20 > (this has some difficulties, because you would need to configure the=20 > DNS servers to different hosts depending on the default router they=20 > use.. This isn't a problem if the host will always use the same default router, e.g., when the default router is co-located on the same physical platform as the host. > in addition, more complexity will arise when you want=20 > to support=20 > fault tolerance when the default router fails) When the host and default router both reside on the same physical platform, then there is no real point in worrying about fault tolerance anyway. Hence, there is no additional complexity. > - The router also needs a DNS alg, to interpret the DNS query sent by=20 > the host and create the additional DNS query to ask for the RLOC RR I'm not sure that "DNS alg" is the right way to call it, but it would appear as an ordinary DNS server to hosts on the inside and as an ordinary DNS client to the network on the outside. =20 > right? Right, and this also goes with what Tony said about having the ITR be co-located on the CE box. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 11:58:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawDS-0007zq-2v; Mon, 09 Apr 2007 11:55:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HawDQ-0007zi-RR for ram@iab.org; Mon, 09 Apr 2007 11:55:36 -0400 Received: from kay.sprintlink.net ([199.0.233.8]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HawDP-00023A-IY for ram@iab.org; Mon, 09 Apr 2007 11:55:36 -0400 Received: from iscserv1.res.sprintlink.net ([199.0.237.253]) by kay.sprintlink.net with ESMTP; 09 Apr 2007 11:55:35 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ao8CACj/GUbHAO39/2dsb2JhbAA X-IronPort-AV: i="4.14,388,1170651600"; d="scan'208"; a="29468721:sNHT27909300" Received: from ra.res.sprintlink.net (ra [199.0.236.20]) by iscserv1.res.sprintlink.net (8.8.8+Sun/8.6.12) with ESMTP id LAA12946; Mon, 9 Apr 2007 11:55:54 -0400 (EDT) Received: from localhost (tseely@localhost) by ra.res.sprintlink.net (8.8.8+Sun/8.8.8) with ESMTP id LAA19169; Mon, 9 Apr 2007 11:55:34 -0400 (EDT) X-Authentication-Warning: ra.res.sprintlink.net: tseely owned process doing -bs Date: Mon, 9 Apr 2007 11:55:34 -0400 (EDT) From: Ted Seely X-X-Sender: To: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: <30e9282ccf9f2f8e012501114b76bdb5@it.uc3m.es> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Cc: Tony Li , 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 Sun, 8 Apr 2007, marcelo bagnulo braun wrote: > > El 08/04/2007, a las 18:03, Tony Li escribi=F3: > > > > >>>>> Consider an ITR/ETR co-located with a PE router. That's very > >>>>> interesting from an operator perspective as they can then > >>>>> effectively change locators for a site without site intervention. > >>>> > >>>> are you considering the case of a multihomed site connected to two > >>>> or more different ISPs? > >>> > >>> Nope, it's interesting even for a singly homed site. > >> > >> so, a single homed site with multiple locators? what would be the > >> motivation for that? do you think this would be a common case? > > > > No, a single locator is still interesting. There are numerous cases > > where, as an ISP grows, they would like to renumber a customer and > > can't today. Typical examples are ISPs that did initial address > > allocations without regard to future deployment of IGP areas, and ISPs > > that acquired other, geographically overlapping ISPs. > > > > A Loc/ID split helps the site have provider independence, and it also > > helps the ISP with internal aggregation. > > > > I see what you mean and it makes sense to me > > but a couple of comments: i) this is not really related to TE, right? > (or at least to inter domain TE) ii) you are assuming provider > independent identifiers? > > >> right, but as long there is no conflict of interests. letting one ISP > >> to forward the traffic through the alternative ISP could generate > >> such conflict of interests... I guess it depends on the pricing > >> structure. I mean, if the end site pays its isp by load, then i guess > >> that maybe the conflict of interests could be avoided, since the > >> incentives seem to lead isps to attract traffic, otoh, if the end > >> site pays flat rate, i can see an incentive for the isp to divert as > >> much traffic as possible to the alternative isp. > > > > You mean an ISP might use traffic engineering to optimize its > > situation? I'm shocked, shocked that you would suggest such a thing! > > ;-) ;-) ;-) > > :-) > of course the ISP may want to do that > > what i would be surprised is that the customer would allow it... i > mean, the client does have to let ISP1 know about ISP2 and its prefix, > in order to let ISP1 to divert the traffic through ISP2, (this would > imply for someone to configure both prefixes in the same box, right?) > and this doesn't makes sense to me so far. > > Also you could end up in a strange/unstable situation where ISP1 push > all the traffic to ISP2 and ISP2 pushes the traffic to ISP1, in order > to. > > So summarizing, i do see a benefit w.r.t. to PI to allow a single box > to contain all the PA locator prefix information and even allowing the > ISP to manage that box, so that intra ISP renumbering events are > transparent to the customer. > > Still i don't see clear that allowing the ISP to manage that box in a > multihoming scenario with multiple ISPs in order to perform TE makes > sense from the client p.o.v. hmmmmm.... last i checked that was Internaps buisiness model, and they seemed to have a healthy number of customers who wanted exactly that. I don't see why in the foreseeable future that would change, and that is the beauty of the outsource model. -ted _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 17:21: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 1Hb1G6-00072i-IU; Mon, 09 Apr 2007 17:18:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb1G4-00072c-V3 for ram@iab.org; Mon, 09 Apr 2007 17:18:40 -0400 Received: from [207.179.9.76] (helo=smtp1.extremenetworks.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb1G1-0002ZA-MA for ram@iab.org; Mon, 09 Apr 2007 17:18:40 -0400 Received: from [10.30.20.240] (unknown [10.30.20.240]) by smtp1.extremenetworks.com (Postfix) with ESMTP id 1D3F37946 for ; Mon, 9 Apr 2007 14:18:32 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) Content-Transfer-Encoding: 7bit Message-Id: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> Content-Type: text/plain; charset=US-ASCII; format=flowed To: ram@iab.org From: RJ Atkinson Date: Mon, 9 Apr 2007 17:18:32 -0400 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.1 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [RAM] Robin Whittle's comments on /8 networks 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 think Robin's claims about little-used or unused /8 networks are largely incorrect. I am familiar with several of those networks, because they belong to customers. In each case that I'm familiar with, there are substantial security measures (e.g. firewalls, IDS/IPSs, packet filters) deployed at/near the edges of those networks. Preventing external probe packets is a very very common security policy for any organisation these days. Yours, Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 17:53:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb1mI-0003Hj-4N; Mon, 09 Apr 2007 17:51:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb1mH-0003He-Ea for ram@iab.org; Mon, 09 Apr 2007 17:51:57 -0400 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 1Hb1mE-000363-3Q for ram@iab.org; Mon, 09 Apr 2007 17:51:57 -0400 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 l39Lpqmb018555 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 9 Apr 2007 14:51:52 -0700 (PDT) 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 l39LppRV002579; Mon, 9 Apr 2007 14:51:52 -0700 (PDT) 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 l39LpoNV002485; Mon, 9 Apr 2007 14:51:51 -0700 (PDT) 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); Mon, 9 Apr 2007 14:51:49 -0700 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] Request to advance RFC4214 to Proposed Standard Date: Mon, 9 Apr 2007 14:51:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6B7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46064728.4000805@piuha.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Request to advance RFC4214 to Proposed Standard Thread-Index: Acduw8c9+oJT4F7eRuidMXVcF9ciXgMLJiKQ References: <39C363776A4E8C4A94691D2BD9D1C9A101774817@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A101774818@XCH-NW-7V2.nw.nos.boeing.com> <4606177E.9070405@piuha.net> <4606444E.1030409@zurich.ibm.com> <46064728.4000805@piuha.net> From: "Templin, Fred L" To: "Jari Arkko" , "Brian E Carpenter" X-OriginalArrivalTime: 09 Apr 2007 21:51:49.0295 (UTC) FILETIME=[4690CBF0:01C77AF1] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: rfc-editor@rfc-editor.org, 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 FYI, this discussion was taken over to the v6ops mailing list with the end result that I sent to the IESG a recommendation to advance RFC4214 to standards-track. See the v6ops mailing list archives (and also new links under "IPvLX" on the RRG wiki page) for the discussion that took place. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Jari Arkko [mailto:jari.arkko@piuha.net]=20 > Sent: Sunday, March 25, 2007 2:56 AM > To: Brian E Carpenter > Cc: Templin, Fred L; ram@iab.org; rfc-editor@rfc-editor.org > Subject: Re: [RAM] Request to advance RFC4214 to Proposed Standard >=20 > Sure -- the plans and opinions of an existing WG in this > space is an input to a sponsoring decision. But for now I > really just wanted to know why Fred thinks its relevant > for the RAM discussion. >=20 > Jari >=20 > Brian E Carpenter kirjoitti: > > Jari, > > > > Speaking as a long time participant in ngtrans/v6ops, > > I believe this request should only be addressed via v6ops, > > which, if I recall correctly, has as its established > > consensus to progress no more IPv6 coexistence techniques. > > > > I'm not saying that consensus can't be changed, but until > > it is, I'd be against AD sponsoring of this request > > (without any comment on the merits of this or other > > proposed additional coexistence techniques). > > > > Brian > > > > >=20 >=20 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 18:34:00 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2PO-0005OK-EY; Mon, 09 Apr 2007 18:32:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb2PN-0005OA-TD for ram@iab.org; Mon, 09 Apr 2007 18:32:21 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb2PM-0004vZ-EY for ram@iab.org; Mon, 09 Apr 2007 18:32:21 -0400 Received: from [10.51.201.163] (vs1.ntta.com [207.198.160.6]) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l39MVtf1096370 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Mon, 9 Apr 2007 18:31:57 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: <20070409144402.6958086AF1@mercury.lcs.mit.edu> References: <20070409144402.6958086AF1@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: Content-Transfer-Encoding: 7bit From: Peter Schoenmaker Subject: Re: [RAM] LISP etc. is not the only path to scalable routing Date: Mon, 9 Apr 2007 18:31:48 -0400 To: Noel Chiappa X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Mon, 09 Apr 2007 18:31:59 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Apr 9, 2007, at 10:44 AM, Noel Chiappa wrote: >> From: Robin Whittle > >> Noel Chiappa wrote: > >>> I am reliably informed .. that the vast majority .. of the gates >>> (and heat/power) in contemporary large routers are consumed by the >>> forwarding, and in particular things like access controls. >>> The RIB and/or FIB are not the issue. > >> With transit routers, I understand that none of this sophistication >> is required for handling the main Internet traffic. > > My original message specified "large routers"; i.e. core routers. > I'm not > sure why core routers need these features, but ISP's apparently use > (and > are willing to pay for) them. From my experience, _Core_ interfaces are always missing the one feature that _I_ really need. Also today's core routers become tomorrow's edge router. peter > > Noel > > _______________________________________________ > 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 Apr 09 21:04:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4kJ-0001Wm-0P; Mon, 09 Apr 2007 21:02:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4kH-0001Wc-SD for ram@iab.org; Mon, 09 Apr 2007 21:02:05 -0400 Received: from pmesmtp01.wcom.com ([199.249.20.1] helo=pmesmtp01.mci.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4kE-000218-GQ for ram@iab.org; Mon, 09 Apr 2007 21:02:05 -0400 Received: from dgismtp02.mcilink.com ([166.38.58.142]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JG90069QC78KA@firewall.mci.com> for ram@iab.org; Tue, 10 Apr 2007 01:01:57 +0000 (GMT) Received: from dgismtp02.mcilink.com ([127.0.0.1]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JG900K3KC7851@dgismtp02.mcilink.com> for ram@iab.org; Tue, 10 Apr 2007 01:01:56 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by dgismtp02.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JG900J9GC7834@dgismtp02.mcilink.com> for ram@iab.org; Tue, 10 Apr 2007 01:01:56 +0000 (GMT) Date: Tue, 10 Apr 2007 01:01:56 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] LISP etc. is not the only path to scalable routing In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Peter Schoenmaker Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <20070409144402.6958086AF1@mercury.lcs.mit.edu> X-Spam-Score: 0.1 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Noel Chiappa , 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 Mon, 9 Apr 2007, Peter Schoenmaker wrote: > > On Apr 9, 2007, at 10:44 AM, Noel Chiappa wrote: > > >> From: Robin Whittle > > > >> Noel Chiappa wrote: > > > >>> I am reliably informed .. that the vast majority .. of the gates > >>> (and heat/power) in contemporary large routers are consumed by the > >>> forwarding, and in particular things like access controls. > >>> The RIB and/or FIB are not the issue. > > > >> With transit routers, I understand that none of this sophistication > >> is required for handling the main Internet traffic. > > > > My original message specified "large routers"; i.e. core routers. > > I'm not > > sure why core routers need these features, but ISP's apparently use > > (and > > are willing to pay for) them. people also don't have to stop 20gbps or 15mpps floods of traffic on their core boxes, oh wait, we do. If it can pass traffic I want/NEED to be able to filter that traffic. Also keep in mind that a 12410/T640/CRS-1 may be an enterprise datacenter device which will possibly have acls/filters on 10GE-type interfaces to protect services in said datacenter. (no reliable/solid 10GE firewall's exist, and you may have multiple 10GE feeds in your DC) Skimping on features never is a good plan :( especially not core features. > > From my experience, _Core_ interfaces are always missing the one > feature that _I_ really need. Also today's core routers become > tomorrow's edge router. also quite true. > > > > > Noel > > > > _______________________________________________ > > 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 Apr 09 21:15:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4wo-0003zH-Rf; Mon, 09 Apr 2007 21:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb4wm-0003yy-Je for ram@iab.org; Mon, 09 Apr 2007 21:15:00 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb4wl-0004kX-Aj for ram@iab.org; Mon, 09 Apr 2007 21:15:00 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 09 Apr 2007 18:14:58 -0700 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 l3A1Ew05014514 for ; Mon, 9 Apr 2007 18:14:58 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3A1Etwn019240 for ; Tue, 10 Apr 2007 01:14:58 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: References: <20070409144402.6958086AF1@mercury.lcs.mit.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72BD492D-C14A-402D-9811-AE73BBD77C7D@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] LISP etc. is not the only path to scalable routing Date: Mon, 9 Apr 2007 18:14:51 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1171; t=1176167698; x=1177031698; c=relaxed/simple; s=sjdkim6002; 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]=20LISP=20etc.=20is=20not=20the=20only=20path=20 to=20scalable=20routing |Sender:=20; bh=imHVYdGIoxSsLgvqVylWHdL2JcG5bEsrFiQTdjtH4B4=; b=kKboJo4Z00b91k6Nq9NNptUNZtUWEKgnxGuAzelWVZM3TYYAT8MyzDalWD1QFlPUiN0kCtio cnmDh3ApjfQSHCeOtz91/khBONjoWli6qahZieLhBr7esjyUk1+OKhMa; Authentication-Results: sj-dkim-6; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim6002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Apr 9, 2007, at 6:01 PM, Chris L. Morrow wrote: > If it can pass traffic I want/NEED to be able > to filter that traffic. Also keep in mind that a 12410/T640/CRS-1 > may be > an enterprise datacenter device which will possibly have acls/ > filters on > 10GE-type interfaces to protect services in said datacenter. (no > reliable/solid 10GE firewall's exist, and you may have multiple > 10GE feeds > in your DC) What we're seeing in many cases is that these features are a) needed at the edge, not the core, and b) they're needed for capacities in the mpps. So, the distinction between core and edge boxes is becoming pretty moot, IMHO; the big, fast boxes are needed in both roles, and so the features available on boxes in the core will increasingly match those of the edge, although some of those features are in many cases going to be primarily utilized on the edge and not in the core. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 23:34:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb75D-0002kJ-1t; Mon, 09 Apr 2007 23:31:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb75B-0002kE-CU for ram@iab.org; Mon, 09 Apr 2007 23:31:49 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb759-0006VZ-2k for ram@iab.org; Mon, 09 Apr 2007 23:31:49 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 1C32059E3D; Tue, 10 Apr 2007 13:31:38 +1000 (EST) Message-ID: <461B050F.9030905@firstpr.com.au> Date: Tue, 10 Apr 2007 13:31:27 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Robin Whittle's comments on /8 networks References: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> In-Reply-To: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 Ran, If this is off-topic for the RAM list, I would appreciate you and anyone else writing to me directly to help me understand the usage or one or more of the /8 networks which are advertised. I know some of them are advertised as multiple BGP routes and do have significant rates of ping-response. In the absence of anything to the contrary, I tentatively assume that if a whole /8 is advertised as one BGP route, then the traffic on this /8 would be pretty light compared to the traffic on a /8 which is advertised as many BGP routes. In this case I tentatively assume that a much lower than average proportion of their IP addresses are used. If I don't get a response from random pings to one in 917 IP addresses, I tentatively assume that few, if any, IP addresses are used, or alternatively that there is a complete block on pings or acknowledgments. Total blocking of pings might make sense if the organisation itself was the only user of those 16 million IP addresses. But in that case, I assume they won't be using more than a fraction of a percent or so, since I can't imagine any organisation needing more than 50,000 or so IP addresses. I will update my page: http://www.firstpr.com.au/ip/host-density-per-prefix/ according to whatever information you or others can provide and will write to this list with a summary of that information. - Robin > I think Robin's claims about little-used or unused /8 networks > are largely incorrect. > > I am familiar with several of those networks, because they > belong to customers. In each case that I'm familiar with, there > are substantial security measures (e.g. firewalls, IDS/IPSs, > packet filters) deployed at/near the edges of those networks. > Preventing external probe packets is a very very common security > policy for any organisation these days. > > Yours, > > Ran _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 09 23:43:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb7Fk-0003Az-Ho; Mon, 09 Apr 2007 23:42:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hb7Fh-0003At-VE for ram@iab.org; Mon, 09 Apr 2007 23:42:41 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hb7Fg-000166-Mg for ram@iab.org; Mon, 09 Apr 2007 23:42:41 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 09 Apr 2007 20:42:39 -0700 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 l3A3gdvt008751 for ; Mon, 9 Apr 2007 20:42:39 -0700 Received: from [10.25.7.115] (rdobbins-vpn-3.cisco.com [10.25.7.115]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id l3A3gdwn025252 for ; Tue, 10 Apr 2007 03:42:39 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <461B050F.9030905@firstpr.com.au> References: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> <461B050F.9030905@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Robin Whittle's comments on /8 networks Date: Mon, 9 Apr 2007 20:42:35 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=705; t=1176176559; x=1177040559; 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]=20Robin=20Whittle's=20comments=20on=20/8=20netw orks |Sender:=20; bh=crWhOk6cSt2Y9Nis9LN5OL4O6++QN2GHA8WgLU1zWIk=; b=iCg6POwJ5fa9OVn8evek2/aaNE5DcSJ0MZmWHqMEhWfheDUhw6KW+eDI2eORDaQ1W7GuMSXM Kc7G2086LvtjAlqGBoZOjPoa41wbrRiUhw66PN0QsNphjwfmeylA/QSi; 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: 798b2e660f1819ae38035ac1d8d5e3ab 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 Apr 9, 2007, at 8:31 PM, Robin Whittle wrote: > But in that case, I assume they won't be using more than > a fraction of a percent or so, since I can't imagine any > organisation needing more than 50,000 or so IP addresses. There are more things in Heaven and Earth, Horatio, Than are dreamt of in your philosophy. ;> There are many such organizations. Ran is correct, there's no way that can be inferred, and the above speculation is incorrect. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 03:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAou-0005pN-8R; Tue, 10 Apr 2007 03:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbAos-0005oG-7E for ram@iab.org; Tue, 10 Apr 2007 03:31:14 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbAm5-0005J0-A0 for ram@iab.org; Tue, 10 Apr 2007 03:28:25 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 705CA59E3D; Tue, 10 Apr 2007 17:28:09 +1000 (EST) Message-ID: <461B3C7E.6040901@firstpr.com.au> Date: Tue, 10 Apr 2007 17:27:58 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Robin Whittle's comments on /8 networks References: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> <461B050F.9030905@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.5 (/) X-Scan-Signature: 0ff9c467ad7f19c2a6d058acd7faaec8 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 message discusses LISP vs. SRAM-based forwarding too. Roland Dobbins wrote: > There are more things in Heaven and Earth, Horatio, > Than are dreamt of in your philosophy. > > ;> This is not my philosophy. It was a tentative assumption I am happy to change with the help of people who know more about this than I do, which includes most people on this list. > There are many such organizations. Ran is correct, there's no way > that can be inferred, and the above speculation is incorrect. I am keen to know details to the contrary. One list member wrote to me privately that a large telco has over 330k individual IP addresses including those for nearly 27k router interfaces, some of which are on /30s. This company doesn't have a complete /8. Even if another organisation with a /8 had this number of IP addresses in use, this would be comparatively low: 2% usage of 16 million. The average ping response rate for all /12 BGP prefixes was 14.7%. I doubt that the organisations with /8s I am thinking of: 3.0.0.0/8 0% May94 General Electric Company 15.0.0.0/8 0% Jul94 Hewlett-Packard Company 16.0.0.0/8 0% Nov94 Digital Equipment Corporation (RIP) 44.0.0.0/8 0% Jul92 Amateur Radio Digital Communicat 45.0.0.0/8 0% Jan95 Interop Show Network 53.0.0.0/8 0% Oct93 Cap Debis CCS 55.0.0.0/8 0% Apr95 Boeing Computer Services 214.0.0.0/8 0% Mar98 US-DOD have anything like 330k IP addresses in use. None of the above returned any ping responses. The other complete BGP advertised /8s had non-zero ping response rates: 4.0.0.0/8 0.5787% Dec92 Bolt Beranek & Newman } Level 3 ISP? 8.0.0.0/8 0.1273% Dec92 Bolt Beranek & Newman } 12.0.0.0/8 3.0266% Jun95 AT&T Bell Laboratories 17.0.0.0/8 0.0058% Jul92 Apple Computer Inc. 18.0.0.0/8 0.1215% Jan94 MIT 32.0.0.0/8 0.0405% Jun94 Norsk Informasjonsteknology 33.0.0.0/8 0.0058% Jan91 DLA Systems Automation Center 35.0.0.0/8 0.0694% Apr94 MERIT Computer Network 38.0.0.0/8 0.3877% Sep94 Performance Systems International 57.0.0.0/8 0.0174% May95 SITA (http://sita.aero) 126.0.0.0/8 0.3414% Jan05 APNIC Apart from the last of these, all the above are old /8 assignments which I suspect are generally being used very lightly (apart from AT&T's /8), in terms of number of IP addresses actually in use, compared to the rest of the advertised address space. I am keen to learn anything to confirm this or to the contrary. There are 318 million IP addresses in these 19 /8s. I am sure that many other BGP prefixes have unacceptably low rates of actual address utilisation, but on average, not as spectacularly low as these /8s. If all DFZ routers, say in 2013 or 2014, had SRAM-based IP forwarding and so were capable of instantly classifying IPv4 packets on /24 boundaries, the above address space could easily be broken up and used very efficiently. This would be administratively easy, since it only negatively impacts a handful of organisations. LISP 1.5+ involves taking away something from most or all ISPs and AS end-user organisations - the BGP routability of the majority of address space - unless LISP is only used for the majority of prefixes assigned by RIRs after LISP becomes practical. I am assuming that there is no direct benefit for the end-user in tunneling through LISP compared to simply advertising the prefix normally. Is this the case? Alternatively, for instance, could LISP help with traffic engineering in some way which is not possible with current BGP routing? Or which could be done with BGP routing but is undesirable on the global scale, due to the load on the whole system of propagating whatever relatively frequent changes the TE involved? With SRAM-forwarding in the DFZ routers, no matter how this small number of /8 organisations have scattered their current usage, they could keep those address ranges, down to /24 boundaries, so they wouldn't need to renumber anything. It is not OK for the world to be running out of IPv4 address space while huge slabs of space remain dramatically under-utilised. The only ways of using the IPv4 address space more efficiently all involve more and more smaller assignments to a growing number of ISPs and AS end-users, most of whom need to multihome. The approaches seem to be: 1 - Build future generations of routers with more and more TCAM etc. to cope with continued growth in the number of advertised prefixes. 2 - Make a large fraction of current and future assigned address space not routable by the global BGP system and rely on LISP 1.5+ or a similar system to tunnel it through the remaining, relatively small, number of BGP advertised prefixes. The number of BGP advertised prefixes will need to grow anyway, as more and more border routers are added. Develop new protocols and centralised databases. Create new router software and potentially hardware to handle the packet analysis, header insertion and removal, mapping cache, DNS handling (or DNS snooping?) - and then deploy a large number of these routers around the edge of the Internet. Would this involve a larger number of routers than would be in the DFZ? 3 - Leave the horse and buggy days of Internet routing behind, install a new generation of SRAM-based routers in the DFZ, forget about route aggregation, and convert the global BGP network into something resembling a flat switched network where a growing number of border routers receive packets on 14.5 million /24 boundaries. IPv4 address space to this granularity can be assigned without concern for network topology, but it is best not to change the assignments for reasons other than long-term network structure and short-term adaptation to failures. At the same time, ideally, achieve similar flat routing for IPv6 - over a smaller range than the current /3. - Robin http://tools.ietf.org/html/draft-whittle-sram-ip-forwarding-01 http://www.firstpr.com.au/ip/sram-ip-forwarding/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 08:12:27 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFBE-0007vW-SJ; Tue, 10 Apr 2007 08:10:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFBD-0007vI-QQ for ram@iab.org; Tue, 10 Apr 2007 08:10:35 -0400 Received: from mtagate1.de.ibm.com ([195.212.29.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbFBC-0005KC-DI for ram@iab.org; Tue, 10 Apr 2007 08:10:35 -0400 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate1.de.ibm.com (8.13.8/8.13.8) with ESMTP id l3ACATnV062680 for ; Tue, 10 Apr 2007 12:10:29 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3ACATo44141088 for ; Tue, 10 Apr 2007 14:10:29 +0200 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3ACATZl015146 for ; Tue, 10 Apr 2007 14:10:29 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3ACASGx015129; Tue, 10 Apr 2007 14:10:29 +0200 Received: from [9.4.210.61] ([9.4.210.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA313228; Tue, 10 Apr 2007 14:10:26 +0200 Message-ID: <461B7EB5.2010707@zurich.ibm.com> Date: Tue, 10 Apr 2007 14:10:29 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] LISP etc. is not the only path to scalable routing References: DEFANGED[2851]:DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing. " " com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> <46139B56.5000202@zurich.ibm.com> <461A33AE.7090508@firstpr.com.au> In-Reply-To: <461A33AE.7090508@firstpr.com.au> 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 Robin, > What my SRAM proposal needs is a more compact handling of the bits > 124 to, for instance 92 (a /35 prefix). This will feel really bad > to anyone who feels good about vast expanses of address space, for > instance on the basis that a single prefix will last an organisation > for decades, no matter how much it expands. But that feeling isn't > necessary in a flat routing model, because each AS end-user or ISP > can easily get more space, non-contiguously, as they need it. You missed my point. Enterprise network managers design addressing plans that covers perhaps hundreds of sites with tens of LANs each. They are not interested in acquiring scraps of address space each time they need some more. This is nothing to do with flat routing; even the largest enterprise networks can easily be flat routed. It's to do with administrative simplicity. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 08:26:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFPP-0000PG-8i; Tue, 10 Apr 2007 08:25:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbFPO-0000PB-A9 for ram@iab.org; Tue, 10 Apr 2007 08:25:14 -0400 Received: from mtagate6.uk.ibm.com ([195.212.29.139]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbFPL-0001Zk-Ud for ram@iab.org; Tue, 10 Apr 2007 08:25:14 -0400 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 l3ACP7WO255050 for ; Tue, 10 Apr 2007 12:25:07 GMT Received: from d06av04.portsmouth.uk.ibm.com (d06av04.portsmouth.uk.ibm.com [9.149.37.216]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3ACP66g2662436 for ; Tue, 10 Apr 2007 13:25:07 +0100 Received: from d06av04.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3ACP69f002980 for ; Tue, 10 Apr 2007 13:25:06 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av04.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3ACP6Gv002972; Tue, 10 Apr 2007 13:25:06 +0100 Received: from [9.4.210.61] ([9.4.210.61]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id OAA367550; Tue, 10 Apr 2007 14:25:05 +0200 Message-ID: <461B8221.7020305@zurich.ibm.com> Date: Tue, 10 Apr 2007 14:25:05 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Robin Whittle Subject: Re: [RAM] Robin Whittle's comments on /8 networks References: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> <461B050F.9030905@firstpr.com.au> In-Reply-To: <461B050F.9030905@firstpr.com.au> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 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 > ...since I can't imagine any > organisation needing more than 50,000 or so IP addresses. Working for an organisation with ~380,000 employees, this doesn't defeat my imagination. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 10:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHRI-0005u0-4u; Tue, 10 Apr 2007 10:35:20 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbHRG-0005to-P4 for ram@iab.org; Tue, 10 Apr 2007 10:35:19 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbHRF-00072w-3C for ram@iab.org; Tue, 10 Apr 2007 10:35:18 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 86455BFD1E; Tue, 10 Apr 2007 16:35:11 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 2AAF9BF714; Tue, 10 Apr 2007 16:35:11 +0200 (CEST) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Tue, 10 Apr 2007 16:35:10 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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 El 09/04/2007, a las 16:58, Templin, Fred L escribi=F3: >> this basically means that: >> >> - The router that will forward the packet should also be >> configured as >> the DNS server for those hosts that use such router to send >> packets to >> a given destination (i.e. the default router is also the DNS server) > > That's right. > >> (this has some difficulties, because you would need to configure the >> DNS servers to different hosts depending on the default router they >> use.. > > This isn't a problem if the host will always use the same > default router, e.g., when the default router is co-located > on the same physical platform as the host. > but you said in the previous mail that a platform could a site, like a=20= plane in this case, a platform can have multiple routers and running an IGP. In the case that the the internal routing changes, then it is complex=20 to make sure that the router is still the DNS server, if you see what i=20= mean >> in addition, more complexity will arise when you want >> to support >> fault tolerance when the default router fails) > > When the host and default router both reside on the same > physical platform, then there is no real point in worrying > about fault tolerance anyway. Hence, there is no additional > complexity. > maybe i don't understand what is your definition of platform I am thinking that we are talking about a host in a site that is served=20= by a set of routers, some of them doing the map and encap. In this=20 case, the router doing the map and encap is also the DNS. If you have=20 an IGP and dynamic routing, there is some compelxity added because of=20 this requirement that the DNS server is colocated with the map and=20 encap router AFAICT >> - The router also needs a DNS alg, to interpret the DNS query sent by >> the host and create the additional DNS query to ask for the RLOC RR > > I'm not sure that "DNS alg" is the right way to call it, > but it would appear as an ordinary DNS server to hosts on > the inside and as an ordinary DNS client to the network on > the outside. right, but it must be able to interpret the DNS queries it receives and=20= generate additional queries based on that. (in any case, i called this=20= way in the P-shim6 proposal, but i may agree with you that this is not=20= the best name) Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 11:45:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIVK-0004bp-4d; Tue, 10 Apr 2007 11:43:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIVI-0004Rk-BT for ram@iab.org; Tue, 10 Apr 2007 11:43:32 -0400 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 1HbIVH-0004uv-3N for ram@iab.org; Tue, 10 Apr 2007 11:43:32 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 10 Apr 2007 08:43:30 -0700 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 l3AFhUJu012402 for ; Tue, 10 Apr 2007 08:43:30 -0700 Received: from [171.70.254.169] (dhcp-171-70-254-169.cisco.com [171.70.254.169]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3AFhUZT003129 for ; Tue, 10 Apr 2007 15:43:30 GMT Mime-Version: 1.0 (Apple Message framework v752.3) In-Reply-To: <461B3C7E.6040901@firstpr.com.au> References: <1250A75F-5CBF-428E-ABED-A31F2178772C@extremenetworks.com> <461B050F.9030905@firstpr.com.au> <461B3C7E.6040901@firstpr.com.au> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <77621A7A-9C91-4DD9-8C1A-A515818F82AD@cisco.com> Content-Transfer-Encoding: 7bit From: Roland Dobbins Subject: Re: [RAM] Robin Whittle's comments on /8 networks Date: Tue, 10 Apr 2007 08:41:06 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=541; t=1176219810; x=1177083810; c=relaxed/simple; s=sjdkim1004; 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]=20Robin=20Whittle's=20comments=20on=20/8=20netw orks |Sender:=20; bh=4lHsEhCE0UTjhfzFA4WY4TFshxz2oxijL/RN5kbVrKI=; b=TyfKcx1n1+soQ18TmeI8/qra16ZXJwb3eb1FInwF0GCvgt5ToCKqaWE2hCfn5WY6Ix5CCrDb awdPJUA3WQ9/epCsY+YHE4YJvZ30qlbVK7PX1SNZE7kCerf14UmLFbkm2RPry4c+taOhu4TThJ 7Xpa/pbW0lbX0hhFClAxW2Sxc=; Authentication-Results: sj-dkim-1; header.From=rdobbins@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f 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 Apr 10, 2007, at 12:27 AM, Robin Whittle wrote: > have anything like 330k IP addresses in use. None of the above > returned any ping responses. These doubts are unfounded for at least for of the ones you list. Again, the fact that one doesn't receiv echo replies is meaningless. iACLs. ----------------------------------------------------------------------- Roland Dobbins // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 12:02:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbInS-0001KU-VQ; Tue, 10 Apr 2007 12:02:18 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbInR-0001KG-OR for ram@iab.org; Tue, 10 Apr 2007 12:02:17 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbInP-0001hi-Qv for ram@iab.org; Tue, 10 Apr 2007 12:02:17 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3AG2Dbx024437 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Apr 2007 09:02:14 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3AG2C9r029375; Tue, 10 Apr 2007 11:02:12 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3AG1pWM028478; Tue, 10 Apr 2007 11:01:53 -0500 (CDT) 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); Tue, 10 Apr 2007 09:01:46 -0700 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Tue, 10 Apr 2007 09:01:45 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd7fXRVzI4gNNBCSxyjv51A5t8SZgABz3BA References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 10 Apr 2007 16:01:46.0320 (UTC) FILETIME=[8A3AE500:01C77B89] X-Spam-Score: 0.0 (/) X-Scan-Signature: 386e0819b1192672467565a524848168 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 > > This isn't a problem if the host will always use the same > > default router, e.g., when the default router is co-located > > on the same physical platform as the host. >=20 > but you said in the previous mail that a platform could a=20 > site, like a plane Yes. > in this case, a platform can have multiple routers and running an IGP. Yes. > In the case that the the internal routing changes, then it is complex=20 > to make sure that the router is still the DNS server, if you=20 > see what i=20 > mean I am thinking that normal IGP routing occurs between routers that are internal to a platform, and map&encaps occurs at the platform boundary routers. If there are multiple platform boundary routers, then there is a need for coordination between the boundary routers. That is a good reason to locate the map&encaps function as close to the end user devices as possible; preferrably on the end devices themselves. =20 > >> in addition, more complexity will arise when you want > >> to support > >> fault tolerance when the default router fails) > > > > When the host and default router both reside on the same > > physical platform, then there is no real point in worrying > > about fault tolerance anyway. Hence, there is no additional > > complexity. >=20 > maybe i don't understand what is your definition of platform >=20 > I am thinking that we are talking about a host in a site that=20 > is served=20 > by a set of routers, some of them doing the map and encap. In this=20 > case, the router doing the map and encap is also the DNS. If you have=20 > an IGP and dynamic routing, there is some compelxity added because of=20 > this requirement that the DNS server is colocated with the map and=20 > encap router AFAICT I am using the terms "platform" and "site" pretty much synonymously, only that a platform is a special kind of site that has "bounded" characteristics. By "bounded", I mean that all nodes within a platform tend to stay connected and move around together as a unit. About sites, a plane is a site; a subnetwork within a plane is also a site; an end user device within a subnetwork within a plane is also a site.(Remember that an end user device can also connect an arbitrarily-complex network, or contain an arbitrarily complex network of internal virtual nodes.) As someone once said (and as I have said on a number of occasions w/o realizing it had already been said by others): "It's turtles all the way down". =20 Pushing the map&encaps function to the sites of finest granularity possible (i.e., preferrably on the end user devices themselves) addresses the issue of coordination between multiple site border routers. =20 > >> - The router also needs a DNS alg, to interpret the DNS=20 > query sent by > >> the host and create the additional DNS query to ask for the RLOC RR > > > > I'm not sure that "DNS alg" is the right way to call it, > > but it would appear as an ordinary DNS server to hosts on > > the inside and as an ordinary DNS client to the network on > > the outside. >=20 > right, but it must be able to interpret the DNS queries it=20 > receives and=20 > generate additional queries based on that. (in any case, i=20 > called this=20 > way in the P-shim6 proposal, but i may agree with you that=20 > this is not=20 > the best name) My knowledge of (P)shim6 is very limited; the name I have been using is IPvLX. Thanks - Fred fred.l.templin@boeing.com > Regards, marcelo _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 12:15:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIzC-0008BN-5y; Tue, 10 Apr 2007 12:14:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbIzA-00088e-HT for ram@iab.org; Tue, 10 Apr 2007 12:14:24 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbIz9-0004U9-1C for ram@iab.org; Tue, 10 Apr 2007 12:14:24 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DE68FC0925; Tue, 10 Apr 2007 18:14:21 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id C695CC08F2; Tue, 10 Apr 2007 18:14:21 +0200 (CEST) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Tue, 10 Apr 2007 18:14:21 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 El 10/04/2007, a las 18:01, Templin, Fred L escribi=F3: > >>> This isn't a problem if the host will always use the same >>> default router, e.g., when the default router is co-located >>> on the same physical platform as the host. >> >> but you said in the previous mail that a platform could a >> site, like a plane > > Yes. > >> in this case, a platform can have multiple routers and running an = IGP. > > Yes. > >> In the case that the the internal routing changes, then it is complex >> to make sure that the router is still the DNS server, if you >> see what i >> mean > > I am thinking that normal IGP routing occurs between > routers that are internal to a platform, and map&encaps > occurs at the platform boundary routers. If there are > multiple platform boundary routers, then there is a need > for coordination between the boundary routers. exactly, this is one form of added complexity that i was mentioning > That is a > good reason to locate the map&encaps function as close to > the end user devices as possible; preferrably on the end > devices themselves. > but then, you have an end host solution and this is not what we are=20 looking for here AFAIU (we already have several of those, and they seem=20= to lack something, hence here we are...) >>>> in addition, more complexity will arise when you want >>>> to support >>>> fault tolerance when the default router fails) >>> >>> When the host and default router both reside on the same >>> physical platform, then there is no real point in worrying >>> about fault tolerance anyway. Hence, there is no additional >>> complexity. >> >> maybe i don't understand what is your definition of platform >> >> I am thinking that we are talking about a host in a site that >> is served >> by a set of routers, some of them doing the map and encap. In this >> case, the router doing the map and encap is also the DNS. If you have >> an IGP and dynamic routing, there is some compelxity added because of >> this requirement that the DNS server is colocated with the map and >> encap router AFAICT > > I am using the terms "platform" and "site" pretty much > synonymously, only that a platform is a special kind of site > that has "bounded" characteristics. By "bounded", I mean that > all nodes within a platform tend to stay connected and move > around together as a unit. > ok > About sites, a plane is a site; a subnetwork within a plane > is also a site; an end user device within a subnetwork within > a plane is also a site.(Remember that an end user device can > also connect an arbitrarily-complex network, or contain an > arbitrarily complex network of internal virtual nodes.) As > someone once said (and as I have said on a number of occasions > w/o realizing it had already been said by others): > > "It's turtles all the way down". > > Pushing the map&encaps function to the sites of finest > granularity possible (i.e., preferrably on the end user > devices themselves) addresses the issue of coordination > between multiple site border routers. > agree, but again, AFAIU, we are into router based solutions here. regards, marcelo >>>> - The router also needs a DNS alg, to interpret the DNS >> query sent by >>>> the host and create the additional DNS query to ask for the RLOC RR >>> >>> I'm not sure that "DNS alg" is the right way to call it, >>> but it would appear as an ordinary DNS server to hosts on >>> the inside and as an ordinary DNS client to the network on >>> the outside. >> >> right, but it must be able to interpret the DNS queries it >> receives and >> generate additional queries based on that. (in any case, i >> called this >> way in the P-shim6 proposal, but i may agree with you that >> this is not >> the best name) > > My knowledge of (P)shim6 is very limited; the name I have > been using is IPvLX. > > Thanks - Fred > fred.l.templin@boeing.com > >> Regards, marcelo > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 12:18:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ2d-0003Dw-H1; Tue, 10 Apr 2007 12:17:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbJ2c-0003Ca-6s for ram@iab.org; Tue, 10 Apr 2007 12:17:58 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbJ2a-000590-Uu for ram@iab.org; Tue, 10 Apr 2007 12:17:58 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3AGHtX8005770 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 10 Apr 2007 09:17:56 -0700 (PDT) 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 l3AGHs9Q014202; Tue, 10 Apr 2007 09:17:54 -0700 (PDT) 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 l3AGHmaa013857; Tue, 10 Apr 2007 09:17:53 -0700 (PDT) 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); Tue, 10 Apr 2007 09:17:52 -0700 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Tue, 10 Apr 2007 09:17:52 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd7i1CY/RQKYSXJQfKpqacyxST5+wAABI0A References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> From: "Templin, Fred L" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 10 Apr 2007 16:17:52.0973 (UTC) FILETIME=[CA666FD0:01C77B8B] X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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 then, you have an end host solution and this is not what we are=20 > looking for here AFAIU (we already have several of those, and=20 > they seem=20 > to lack something, hence here we are...) No; it is a router-based solution. That the router may connect *very* closely to the end host is immaterial, and AFAICT incremental deployment is already underway... 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 Tue Apr 10 14:33:49 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbL8x-0007Ot-CA; Tue, 10 Apr 2007 14:32:39 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbL8w-0007N9-AF for ram@iab.org; Tue, 10 Apr 2007 14:32:38 -0400 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 1HbL8v-0000uh-0J for ram@iab.org; Tue, 10 Apr 2007 14:32:38 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 10 Apr 2007 11:32:36 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3AIWaGd016098; Tue, 10 Apr 2007 11:32:36 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3AIWZEk018087; Tue, 10 Apr 2007 18:32:36 GMT 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, 10 Apr 2007 11:32:35 -0700 Received: from [192.168.0.100] ([10.21.102.14]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 11:32:34 -0700 In-Reply-To: <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Tue, 10 Apr 2007 11:32:27 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Apr 2007 18:32:35.0282 (UTC) FILETIME=[9BD4EB20:01C77B9E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=734; t=1176229956; x=1177093956; c=relaxed/simple; s=sjdkim3002; 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=20DNS=20ALG=20(was=20Re=3A=20[RAM]=20Incremental=20Depl oyment=20of=20LISP |Sender:=20; bh=yGmSFMJxFq9KiLf1AlAvfKUDlPEmq9YJc2WELOQoQGo=; b=JKd7uM4I0WGK3xUShhxNmxUbZzyTBUOXCTUdBvgHS+ue9f9RRjHHAj/RMz3ovn5sC3lMPpyE HosPn3tYdrmU40mhFp9e/8azNzfg1X3W1U7dKXQ8M/vp0jmXF/7JfYBM; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: "Templin, Fred L" , 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 Apr 10, 2007, at 9:14 AM, marcelo bagnulo braun wrote: > but then, you have an end host solution and this is not what we are > looking for here AFAIU (we already have several of those, and they > seem to lack something, hence here we are...) Just so that we're all on the same page, what is it that they are lacking? My read is that they lack scalable manageability. Putting a middlebox solution in place is not so much to shift the complexity off the hosts, but to centralize the management of the mechanisms, turning an O(n) problem into an O(1) problem. Thus, pushing the heavy lifting to the host while centralizing the management should still be an acceptable strategy to folks. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 14:50:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLOx-0007oE-EE; Tue, 10 Apr 2007 14:49:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbLOv-0007ju-Ua for ram@iab.org; Tue, 10 Apr 2007 14:49:09 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbLOu-0006xk-Mu for ram@iab.org; Tue, 10 Apr 2007 14:49:09 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 10 Apr 2007 14:49:01 -0400 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3AIn0nq023301; Tue, 10 Apr 2007 14:49:00 -0400 Received: from [64.101.199.95] (dhcp-64-101-199-95.cisco.com [64.101.199.95]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3AImtGd026483; Tue, 10 Apr 2007 18:48:55 GMT Message-ID: <461BDC16.80501@cisco.com> Date: Tue, 10 Apr 2007 14:48:54 -0400 From: Russ White User-Agent: Thunderbird 1.5.0.10 (Macintosh/20070221) MIME-Version: 1.0 To: Tony Li Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> In-Reply-To: <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> X-Enigmail-Version: 0.94.3.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1227; t=1176230940; x=1177094940; c=relaxed/simple; s=rtpdkim2001; 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=20DNS=20ALG=20(was=20Re=3A=20[RAM]=20Incremental=20Depl oyment=20of=20LISP |Sender:=20 |To:=20Tony=20Li=20; bh=nOZ4yqdY9QvDYxVhXDzpkpgya9r42GbgnsG2rhurUaY=; b=oO0uBZgqozZ7dLPoFWK4A/PgePIIPPhqr2tQEQmb2w2S91TIayDXWzVVmtB8NvaCWn5OF0zl HcslIHmGI6ANpayHo0O9S6m9lwqn5JMfIPSBYXaW5Lzr83qqXZaE60HH; Authentication-Results: rtp-dkim-2; header.From=riw@cisco.com; dkim=pass (si g from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: "Templin, Fred L" , 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 >> but then, you have an end host solution and this is not what we are >> looking for here AFAIU (we already have several of those, and they >> seem to lack something, hence here we are...) > > Just so that we're all on the same page, what is it that they are lacking? I think the main objection will be on the management side of things.... OTOH, I think most of the host based solution objections presume something like shim6, which is not the only possible host based solution. IMHO, we should look at the full range of solutions on the host and in the network, and try to understand the tradeoffs vis-a-vis the problem (and maybe we actually need a problem statement someplace?).... I can see a solution where you move DNS type services closer to the default router, perhaps even into the default router (what, after all, is SAF all about?), and using host based solutions to solve the rest of the puzzle. :-) Russ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.3 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGG9wWER27sUhU9OQRAgV3AKDpR3Gt+1uAIefTU7LGgeDM+VegnwCfVovU lLKIxTrod1NG2RbEN2PVpM8= =wWXh -----END PGP SIGNATURE----- _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 16:01:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMVc-00059u-UK; Tue, 10 Apr 2007 16:00:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMVb-00059O-Gb for ram@iab.org; Tue, 10 Apr 2007 16:00:07 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMVY-0003lr-1F for ram@iab.org; Tue, 10 Apr 2007 16:00:07 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id CEC5F118D36; Tue, 10 Apr 2007 22:00:02 +0200 (CEST) Received: from localhost (webcartero01.uc3m.es [163.117.136.131]) by smtp02.uc3m.es (Postfix) with ESMTP id 39D37118D32; Tue, 10 Apr 2007 22:00:00 +0200 (CEST) Received: from 187.45.217.87.dynamic.jazztel.es (187.45.217.87.dynamic.jazztel.es [87.217.45.187]) by webcartero01.uc3m.es (Horde MIME library) with HTTP; Tue, 10 Apr 2007 21:59:57 +0200 Message-ID: <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> Date: Tue, 10 Apr 2007 21:59:57 +0200 From: MARCELO BAGNULO BRAUN To: Tony Li Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> In-Reply-To: <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.0.4) X-Spam-Score: 1.5 (+) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: "Templin, Fred L" , 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 Tony Li dijo: > > On Apr 10, 2007, at 9:14 AM, marcelo bagnulo braun wrote: > >> but then, you have an end host solution and this is not what we are >> looking for here AFAIU (we already have several of those, and they >> seem to lack something, hence here we are...) > > > Just so that we're all on the same page, what is it that they are lacking? yes this seems a good excersise > > My read is that they lack scalable manageability. not sure i understand what you mean... do you think that exposing n PA locators/addresses to end hosts is acceptable or this is part of the management problem (in the sense that you need to configure and manage n prefixes in every host) i don't know if this is really a management problem since it seems easy to extend the autoconf mechanisms to configure n addresses instead of 1 I think that the problems may be that: - once you expose the n locators to the host, you transfer to the hosts themsleves the part of the path selection, in particular the selection of the exit path/ingress path. this seems to change the power balance from todays situation. In particular, policing now is up the hosts. Note that it would be easy to define some automatic mechanism to distribute RFC3484 policy table through the hosts, but what it seems to be lacking is a central mechanism to _enforce_ that policy i.e. the final decision is still up to the end hosts. Besides, exposing n locators to the multihomed site allow the end site to have much more control on what path to use for a given packet and the ISPs cannot longer influence the path of packets tunning BGP. So again, here there is a change in the power balance, from the isps to the end site. So, i see that there are two changes in the balance of power: - the hosts have the decision of what exit path to use for their packets and there is no centralized way to enforce site wide policy - the site has tighther control on the path used for its packets and the ISPs have less control on the traffic of their multihomed customers finally, if you expose the n locators/addresses to the hosts, you increase provider captivity, since you increase the cost of renumbering So, for me, they key issue is whether the hosts are configured with the n PA locators or not. If the n prefixes are in reduced set of boxes, then, these boxes have the power to control the locators, hence they can enforce the policy. So probably, if we want to explore other part of the solution space different than previous solutions, we should limit ourselves to solutions that do not expose n PA prefices to the hosts and only a limited set of boxes have the PA address information. regards, marcelo > Putting a middlebox solution in place is not so much to shift the > complexity off the hosts, but to centralize the management of the > mechanisms, turning an O(n) problem into an O(1) problem. > > Thus, pushing the heavy lifting to the host while centralizing the > management should still be an acceptable strategy to folks. > > Tony > -- ---- MARCELO BAGNULO BRAUN WebCartero Universidad Carlos III de Madrid _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 10 16:25:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMsw-0005TV-Nl; Tue, 10 Apr 2007 16:24:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbMsv-0005TO-WB for ram@iab.org; Tue, 10 Apr 2007 16:24:14 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbMst-0002Pt-I5 for ram@iab.org; Tue, 10 Apr 2007 16:24:13 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 10 Apr 2007 13:24:07 -0700 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3AKO6NF026286; Tue, 10 Apr 2007 13:24:06 -0700 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 l3AKNYFM008969; Tue, 10 Apr 2007 20:24:06 GMT 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, 10 Apr 2007 13:24:02 -0700 Received: from [192.168.0.100] ([10.21.102.14]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Apr 2007 13:24:01 -0700 In-Reply-To: <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Tue, 10 Apr 2007 13:24:00 -0700 To: MARCELO BAGNULO BRAUN X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 10 Apr 2007 20:24:01.0954 (UTC) FILETIME=[2D661820:01C77BAE] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3268; t=1176236647; x=1177100647; c=relaxed/simple; s=sjdkim1004; 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=20DNS=20ALG=20(was=20Re=3A=20[RAM]=20Incremental=20Depl oyment=20of=20LISP |Sender:=20; bh=1n/lPSEFA0mIbyeImhQSV2ZloYj+hon4HalaAMNfP9k=; b=KCOUhYLVLidpQDSZ4uY5+c36cbXIShxBmoofvvMRKiWTIprTSUhK1/vtNX5QPXixyBEByNh8 M0or+rMF5mBO6xzeN2LlZRZsxRvo/RXosG/BdR2ZJDQLWgOZwXpcVcjy9Y/3RrVHiMl5u1T7vb 9A514gOJoYteAySGJ9H6FD7Kw=; Authentication-Results: sj-dkim-1; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: "Templin, Fred L" , 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 >> My read is that they lack scalable manageability. > > do you think that exposing n PA locators/addresses to end hosts is > acceptable or this is part of the management problem (in the sense > that you need to configure and manage n prefixes in every host) Yes, that's part of the management problem. I think that most folks are trying to get *away* from managing individual hosts, just so we don't turn entire city-sized populations into sysadmins. > i don't know if this is really a management problem since it seems > easy to extend the autoconf mechanisms to configure n addresses > instead of 1 Yes, you could do that, but then there's policy on top of that, as you write below. > I think that the problems may be that: > - once you expose the n locators to the host, you transfer to the > hosts themsleves the part of the path selection, in particular the > selection of the exit path/ingress path. this seems to change the > power balance from todays situation. In particular, policing now is > up the hosts. Note that it would be easy to define some automatic > mechanism to distribute RFC3484 policy table through the hosts, but > what it seems to be lacking is a central mechanism to _enforce_ > that policy i.e. the final decision is still up to the end hosts. > > Besides, exposing n locators to the multihomed site allow the end > site to have much more control on what path to use for a given > packet and the ISPs cannot longer influence the path of packets > tunning BGP. So again, here there is a change in the power balance, > from the isps to the end site. > > So, i see that there are two changes in the balance of power: > - the hosts have the decision of what exit path to use for their > packets and there is no centralized way to enforce site wide policy > - the site has tighther control on the path used for its packets > and the ISPs have less control on the traffic of their multihomed > customers Yup, those are the management problems that I was getting at. I'm more concerned about the former than the latter. > finally, if you expose the n locators/addresses to the hosts, you > increase provider captivity, since you increase the cost of > renumbering I'm not really buying that. It seems that if you have autoconf mechanisms in place, the costs of adding or changing locators should be incremental. > So, for me, they key issue is whether the hosts are configured with > the n PA locators or not. > If the n prefixes are in reduced set of boxes, then, these boxes > have the power to control the locators, hence they can enforce the > policy. > > So probably, if we want to explore other part of the solution space > different than previous solutions, we should limit ourselves to > solutions that do not expose n PA prefices to the hosts and only a > limited set of boxes have the PA address information. By your analysis above, this seems overly restrictive. Shouldn't we bound the solution space by the manageability concerns? If there was a solution that did distribute PA prefixes but retained centralized path control, wouldn't that be acceptable? Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 01:18: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 1HbVBr-0008JT-K9; Wed, 11 Apr 2007 01:16:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbVBp-0008Ga-Sv for ram@iab.org; Wed, 11 Apr 2007 01:16:17 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbVBn-00089O-UA for ram@iab.org; Wed, 11 Apr 2007 01:16:17 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 165F559E43; Wed, 11 Apr 2007 15:16:06 +1000 (EST) Message-ID: <461C6F0B.7000901@firstpr.com.au> Date: Wed, 11 Apr 2007 15:15:55 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP etc. is not the only path to scalable routing References: DEFANGED[2851]:DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing. " " com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> <46139B56.5000202@zurich.ibm.com> <461A33AE.7090508@firstpr.com.au> <461B7EB5.2010707@zurich.ibm.com> In-Reply-To: <461B7EB5.2010707@zurich.ibm.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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 Brian, I accept that the most administratively simple approach to address assignment is for an ISP or AS end-user organisation to get a single block of address space which is big enough to suit its greatest possible needs for the next decade or two. The two reasons for providing such a large, single, long-lasting block seem to be this administrative simplicity and the desire for route aggregation. Most users of an address block such as this will want to split it geographically for its various branch offices, and for each office (or even for a small organisation with a single site) to split it and advertise it on topologically diverse parts of the Net. The more topologically diverse, the better, in terms of providing robust multihoming. So I think the goal of assigning larger blocks less frequently for the purpose of preserving route aggregation is illusory. This leaves the other goal of administrative simplicity for each medium to large organisation. I assume that small organisations with a single site could get by with a single assignment for quite a number of years - for instance a /22 to /24which they can advertise as one or more separate/24s for multihoming. There is also the goal of administrative simplicity for RIRs handing out a large block at one time rather than a lot of smaller blocks more frequently. The trouble is with the traditional approach to address assignment is that really large slabs of address space are assigned, with generally minimal utilisation - with the result that we are running out of fresh address space. Then everyone has to adopt LISP or IPv6, both of which have a bunch of costs and problems. I don't think that the immense global, shared, cost of: 1 - Being forced into IPv6 just due to shortage of fresh address space in IPv4. or 2 - Having to pay for massive TCAM in all DFZ routers. or 3 - Having to change IPv4 usage such as with LISP, including new routers all over the edge of the network, and a large subset of address space being excluded from being the BGP routing system. is justified by the administrative simplicity of medium and larger users having a single slab of addresses, compared to them getting multiple smaller blocks as they need them and the deployment of a new generation of SRAM-based DFZ routers. I think we may be able to avoid 2 and 3 above, and not be forced into IPv6 for another decade or more, if the IPv4 address space is used much more efficiently. To do this, it needs to be sliced and diced with freedom. In the past, routers couldn't be built to handle this. Now I believe they can. For my suggestion to be practical, there needs to be more CPU power and RAM in the DFZ routers and the changes in BGP advertised prefixes probably need to be restricted to long-term changes reflecting basic network topology and to short-term changes due to genuine outages. I do not propose the global BGP system be loaded down by some prefixes being changed for short-term, recurring purposes, such as adapting to daily changes in traffic patterns. Since the DFZ routers will all be replaced in 5 years or less, I suggest the new ones be equipped with SRAM so they easily route (or perhaps switch) packets to 14.5 million freely assignable IPv4 /24 prefixes. This should require minimal incremental expense in the DFZ, which all Net users share. It requires no expenditure on LISP routers in provider and AS end-user networks. It requires no inefficient headers, new protocols or centralised mapping databases. I think these aspects of LISP, including - as best I can understand - the need (with LISP 1.5+) to remove a substantial proportion of the address space from the global BGP system and handle it with LISP, would be more administratively complex than medium to large organisations having to get address space in smaller, non-contiguous, chunks. - Robin > Robin, > >> What my SRAM proposal needs is a more compact handling of the >> bits 124 to, for instance 92 (a /35 prefix). This will feel >> really bad to anyone who feels good about vast expanses of >> address space, for instance on the basis that a single prefix >> will last an organisation for decades, no matter how much it >> expands. But that feeling isn't necessary in a flat routing >> model, because each AS end-user or ISP can easily get more space, >> non-contiguously, as they need it. > > You missed my point. Enterprise network managers design > addressing plans that covers perhaps hundreds of sites with tens > of LANs each. They are not interested in acquiring scraps of > address space each time they need some more. This is nothing to do > with flat routing; even the largest enterprise networks can easily > be flat routed. > It's to do with administrative simplicity. > > Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 03:22:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbX8H-00086X-7V; Wed, 11 Apr 2007 03:20:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbX8G-00086K-Gy for ram@iab.org; Wed, 11 Apr 2007 03:20:44 -0400 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbX8E-0004Fz-7t for ram@iab.org; Wed, 11 Apr 2007 03:20:43 -0400 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 l3B7Ke2a078082 for ; Wed, 11 Apr 2007 07:20:40 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.3) with ESMTP id l3B7KeY72043976 for ; Wed, 11 Apr 2007 08:20:40 +0100 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 l3B7Kdme029655 for ; Wed, 11 Apr 2007 08:20:40 +0100 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 l3B7KduH029651; Wed, 11 Apr 2007 08:20:39 +0100 Received: from [9.4.210.149] ([9.4.210.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id JAA368372; Wed, 11 Apr 2007 09:20:38 +0200 Message-ID: <461C8C4A.8050102@zurich.ibm.com> Date: Wed, 11 Apr 2007 09:20:42 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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-04-10 18:17, Templin, Fred L wrote: >> but then, you have an end host solution and this is not what we are >> looking for here AFAIU (we already have several of those, and >> they seem >> to lack something, hence here we are...) > > No; it is a router-based solution. That the router may > connect *very* closely to the end host is immaterial, > and AFAICT incremental deployment is already underway... One of the trickiest problems we saw in the shim6 variant of this is exit router selection, when different routers are connected to different ISPs. That breaks any 1:1 relationship between hosts and exit routers, and pretty much requires some additional mechanism. I think that has to be added to the list of management gaps. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 04:30:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbYD0-0000S5-6f; Wed, 11 Apr 2007 04:29:42 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbYCz-0000Pe-5H for ram@iab.org; Wed, 11 Apr 2007 04:29:41 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbYCx-0002ZA-Rp for ram@iab.org; Wed, 11 Apr 2007 04:29:41 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 11 Apr 2007 01:29:39 -0700 X-IronPort-AV: i="4.14,393,1170662400"; d="scan'208"; a="134378848:sNHT43779402" 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 l3B8TdZ7013319; Wed, 11 Apr 2007 01:29:39 -0700 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 l3B8TWMF028808; Wed, 11 Apr 2007 08:29:32 GMT 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); Wed, 11 Apr 2007 01:29:32 -0700 Received: from [192.168.0.4] ([10.21.90.45]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 01:29:31 -0700 In-Reply-To: <461C6F0B.7000901@firstpr.com.au> References: DEFANGED[2851]:DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing. " " com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> <46139B56.5000202@zurich.ibm.com> <461A33AE.7090508@firstpr.com.au> <461B7EB5.2010707@zurich.ibm.com> <461C6F0B.7000901@firstpr.com.au> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <105FF864-A00A-41AF-A5F1-30FBE399A928@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] LISP etc. is not the only path to scalable routing Date: Wed, 11 Apr 2007 01:29:37 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Apr 2007 08:29:31.0894 (UTC) FILETIME=[8743D160:01C77C13] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=801; t=1176280179; x=1177144179; 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]=20LISP=20etc.=20is=20not=20the=20only=20path=20 to=20scalable=20routing |Sender:=20; bh=EmH/Hfy7PQVxWxAeQB9FNKx4A0TVa8Zbzcoh/TeJ56M=; b=dPMFVfgO3N42qBhdr9bmERigxeMyqEMjWmfxLN6JvFAIR4qsegaobY4WYMzVp2rnFIg+M7di UkxxO2sC3ppTTcIk8iXiWWl/ewk3sb9n4pOhpE4+H5gyd76EVJWRmRZi; 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: 08170828343bcf1325e4a0fb4584481c 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 think these aspects of LISP, including - as best I can understand > - the need (with LISP 1.5+) to remove a substantial proportion of > the address space from the global BGP system and handle it with > LISP, would be more administratively complex than medium to large > organisations having to get address space in smaller, > non-contiguous, chunks. Allow me to clarify one point. LISP does not remove the topologically significant locator prefixes from the core. They will use traditional CIDR aggregation as they have been since CIDR has been introduced. It is the PI prefixes which are not aggregatable that need to removed at the same time as allowing site-based and provider-based ingress traffic engineering without advertising more specific routes to do so. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 05:05:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbYlM-0001IZ-FA; Wed, 11 Apr 2007 05:05:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbYlK-0001IM-AU for ram@iab.org; Wed, 11 Apr 2007 05:05:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbYlH-0005UT-ST for ram@iab.org; Wed, 11 Apr 2007 05:05:10 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2007 02:05:07 -0700 X-IronPort-AV: i="4.14,393,1170662400"; d="scan'208"; a="410184802:sNHT54462662" Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3B956fY008933; Wed, 11 Apr 2007 02:05:06 -0700 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 l3B94vMF018284; Wed, 11 Apr 2007 09:05:02 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 02:04:57 -0700 Received: from [192.168.0.4] ([10.21.90.45]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 02:04:56 -0700 In-Reply-To: <816668963e0ee48143c31b9006c551d0@it.uc3m.es> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 02:05:02 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Apr 2007 09:04:56.0584 (UTC) FILETIME=[79ADC880:01C77C18] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3626; t=1176282306; x=1177146306; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=lquVsl6eBcARWvmzdvqIVChnG9rF/HbHPL3WgUJMPsE=; b=TKgo3LO8GPoHTJZhRN9YIuZ1lXJQ15dNtFMDIX0EhqatwPKAEJgpkgkN/byh9/XQGUNU+azt FAAfk2g0NaC5hLsxw5d/XMoOeKcEuu0ZE0SCnrXYMpBINBFXGKe4GdETK9pwbC8AbFznfVj8v8 EJpsuKo3fWhDPaTh1oXhn+M4g=; 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: 32b73d73e8047ed17386f9799119ce43 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 Sorry for the delay on this response. >>>> You are right non Marcelo. I think taking the high-road by doing >>>> a LISP-push model gives you the best of all worlds. >>> >>> by push model, we are talking about destributing the ID to >>> locator mapping database to all LISP routers? >> >> I would say all high-level routers > > i am not sure what do you mean by high level router... could you > expand? I mean a set of routers at the highest level of a hierarchy. > but the ITR are the ones than need the information (hence the ones > that should have it), right? > > Of course, in addition, routers making TE would also benefit from > it, so it makes sense to pass it to them also (but they are ITRs > after all, right?) If they have the storage capacity sure, but when they don't they have to be cache based and send queries for the mapping they need. There are only two ways to do this. >>> are you thinking in using a protocol for that distribution, like >>> BGP for instance? >> >> A new protocol more optimized perhaps for flooding that has >> authentication built-in. >> > > what is the motivation for a new protocol? Because there isn't anything out there that can flood (without doing other things) as well as authenticate bindings. > i mean, BGP does seem to provide what is needed, and it is well > known by the community Every BGP router may not be an ITR/ETR or high-level router. So you are storing the information in places you don't need it. That means everyone is paying the cost. If we are worried about power, FIB size and line-card costs, we need to move this state to the edges in lesser expensive memories. > do you think that BGP is lacking some of the required capabilities? Yep. Plus it has more than we want. And many have shown that BGP is not an efficient flooding protocol. > note that for globally distributing the ID to locator mapping > information, you would just need to enable another instance of BGP > with maybe some extensions, that would That was a possibility we considered with LISP 1.5. That is, to change less protocols and have a non-topological aggregation benefit as Vince has outlined a number of times. > carry the id to loc mapping to all the routers running this new > instance. I think that from a deployment perspective, this is much > better than designing a new protocol, since it would only require > configure existent routers (maybe some software patch) but not > deploying a new protocol (I think this would go along with the > general LISP policy of minor changes rather than new protocols, > doesn't it?) A new protocol can start simple. We made this decision with MSDP. We decided it was better to not put the frequency of multicast source discovery in BGP, and I stand by that decision today being a good one. BGP already does too many things. And if you want to tweak it to optimize one thing it may have negative effect on other things. >>> There have been a few proposals on this area before, which were >>> very interesting imho, but i guess some people though they were >>> too complex >> >> We can start simple. This doesn't need to be complex and if we >> keep policy out of it ;-) we can keep it easier > > but probably the complex part of policy is to provide enough > information and flexibility to allow for local configurations, so > this needs to be build in the protocol from scratch, just as BGP > has it. Not convinced yet the policy has to be as advanced as BGP. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 05:37:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZEq-0000CI-TV; Wed, 11 Apr 2007 05:35:40 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZEo-0000Af-GI for ram@iab.org; Wed, 11 Apr 2007 05:35:38 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HbZEm-00039t-NA for ram@iab.org; Wed, 11 Apr 2007 05:35:38 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4A233179311; Wed, 11 Apr 2007 11:35:35 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id 1971D178CFC; Wed, 11 Apr 2007 11:35:35 +0200 (CEST) In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 11:35:35 +0200 To: Tony Li X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: "Templin, Fred L" , 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 El 10/04/2007, a las 22:24, Tony Li escribi=F3: > >> finally, if you expose the n locators/addresses to the hosts, you=20 >> increase provider captivity, since you increase the cost of=20 >> renumbering > > > I'm not really buying that. It seems that if you have autoconf=20 > mechanisms in place, the costs of adding or changing locators should=20= > be incremental. > but the problem is not changing the IP configured in interfaces,=20 because, you can use autconf mechanims The problem is that PA addresses, if exposed to the intra site domain,=20= may end up in various configurations, like filters, ACL applications=20 and so on. There seems to be little chance that there will be automatic=20= autconf for these other usages. So, i would say that one option to get rid of PA addresses is just to=20 avoid having them present in the intra domain I know it may be overly restricitve as you mention, but this seems to=20 clearly solve all these problems. BAsically, these seems to be one of=20 the advantages that people find in NAT, so maybe it would be a good=20 approach try to keep such feature while solving the problems of NAT=20 (like restoring the end to end identifier seen by the endpoints) > >> So, for me, they key issue is whether the hosts are configured with=20= >> the n PA locators or not. >> If the n prefixes are in reduced set of boxes, then, these boxes have=20= >> the power to control the locators, hence they can enforce the policy. >> >> So probably, if we want to explore other part of the solution space=20= >> different than previous solutions, we should limit ourselves to=20 >> solutions that do not expose n PA prefices to the hosts and only a=20 >> limited set of boxes have the PA address information. > > > By your analysis above, this seems overly restrictive. Shouldn't we=20= > bound the solution space by the manageability concerns? If there was=20= > a solution that did distribute PA prefixes but retained centralized=20 > path control, wouldn't that be acceptable? > i guess so, if you include in management centralized path control (and=20= enforcement), avoiding provider captivity. Another issue that comes=20 into play here, is the deployment phase i.e. how do deal with=20 hosts/sites that do not support the new protocol and only run legacy=20 IP. Regards, marcelo > Tony > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 05:58:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZaw-0003E1-GV; Wed, 11 Apr 2007 05:58:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZav-0003By-7m for ram@iab.org; Wed, 11 Apr 2007 05:58:29 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbZas-0002Kl-6O for ram@iab.org; Wed, 11 Apr 2007 05:58:29 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id DDC54179FA5; Wed, 11 Apr 2007 11:58:22 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id AB1F117A031; Wed, 11 Apr 2007 11:58:22 +0200 (CEST) In-Reply-To: <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 11:58:23 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 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 El 11/04/2007, a las 11:05, Dino Farinacci escribi=F3: > >> but the ITR are the ones than need the information (hence the ones=20 >> that should have it), right? >> >> Of course, in addition, routers making TE would also benefit from it,=20= >> so it makes sense to pass it to them also (but they are ITRs after=20 >> all, right?) > > If they have the storage capacity sure, but when they don't they have=20= > to be cache based and send queries for the mapping they need. There=20 > are only two ways to do this. > so are you envisioning an hybrid system that has both the push and pull=20= models? In such scheme there would be these mesh of high level routers=20= that exchange the whole loc id mapping database and then smaller=20 routers that use the pull model to query these high level routers? the new protocol would then run between these high level routers, is=20 that it? >>>> are you thinking in using a protocol for that distribution, like=20 >>>> BGP for instance? >>> >>> A new protocol more optimized perhaps for flooding that has=20 >>> authentication built-in. >>> >> >> what is the motivation for a new protocol? > > Because there isn't anything out there that can flood (without doing=20= > other things) as well as authenticate bindings. > >> i mean, BGP does seem to provide what is needed, and it is well known=20= >> by the community > > Every BGP router may not be an ITR/ETR or high-level router. So you=20 > are storing the information in places you don't need it. That means=20 > everyone is paying the cost. > > If we are worried about power, FIB size and line-card costs, we need=20= > to move this state to the edges in lesser expensive memories. > i think i didn't explained myself properly I am not saying to use the BGP instance used today to exchange routing=20= information to also exchange loc/id mapping information. What i am saying is using the BGP protocol for that, meaning to create=20= a _new_ instance of BGP and run it for instance between the high level=20= routers that you mention above. In this case, these high level routers=20= would run two instances of BGP. On instance of BGP, that would=20 distribute routing information as it is done today. Another instance of=20= BGP would be used to distribute the id loc mapping information >> do you think that BGP is lacking some of the required capabilities? > > Yep. Plus it has more than we want. And many have shown that BGP is=20 > not an efficient flooding protocol. > i don't know about that... i mean, BGP as a protocol seems to be quite=20= simple and eficient and it is already out there I mean, i do agree that BGP does provide some features that may not be=20= needed for an id loc mapping protocol, but i am not sure this=20 outwiegths the benefits of being a protocol already available in=20 deployed routers >> note that for globally distributing the ID to locator mapping=20 >> information, you would just need to enable another instance of BGP=20 >> with maybe some extensions, that would > > That was a possibility we considered with LISP 1.5. i don't think this is similar than LISP 1.5, please see below... > That is, to change less protocols and have a non-topological=20 > aggregation benefit as Vince has outlined a number of times. > >> carry the id to loc mapping to all the routers running this new=20 >> instance. I think that from a deployment perspective, this is much=20 >> better than designing a new protocol, since it would only require=20 >> configure existent routers (maybe some software patch) but not=20 >> deploying a new protocol (I think this would go along with the=20 >> general LISP policy of minor changes rather than new protocols,=20 >> doesn't it?) > > A new protocol can start simple. We made this decision with MSDP. We=20= > decided it was better to not put the frequency of multicast source=20 > discovery in BGP, and I stand by that decision today being a good one. > > BGP already does too many things. And if you want to tweak it to=20 > optimize one thing it may have negative effect on other things. > I am not saying to overload BGP with additional information, but to run=20= a different instance of BGP to distribute other information. It is=20 similar to the considerations being made about the differences between=20= the DNS protocol and the DNS system. I am not proposing to use current=20= BGP system (the instace of BGP used to currently distribute routing=20 information) but to build another instance of the BGP protocol to=20 distribute the id loc mapping information. Re use the BGP protocol not=20= the current BGP routing system >>>> There have been a few proposals on this area before, which were=20 >>>> very interesting imho, but i guess some people though they were too=20= >>>> complex >>> >>> We can start simple. This doesn't need to be complex and if we keep=20= >>> policy out of it ;-) we can keep it easier >> >> but probably the complex part of policy is to provide enough=20 >> information and flexibility to allow for local configurations, so=20 >> this needs to be build in the protocol from scratch, just as BGP has=20= >> it. > > Not convinced yet the policy has to be as advanced as BGP. policy seems to be one of the key features that are missing in=20 available solutions, so i would put quite some focus on that Regards, marcelo > > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 06:01:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZdH-0004nB-BY; Wed, 11 Apr 2007 06:00:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbZdG-0004n5-1I for ram@iab.org; Wed, 11 Apr 2007 06:00:54 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbZdD-0002Xz-Mz for ram@iab.org; Wed, 11 Apr 2007 06:00:54 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-5.cisco.com with ESMTP; 11 Apr 2007 03:00:51 -0700 X-IronPort-AV: i="4.14,393,1170662400"; d="scan'208"; a="410196209:sNHT49604216" Received: from sj-core-3.cisco.com (sj-core-3.cisco.com [171.68.223.137]) by sj-dkim-6.cisco.com (8.12.11/8.12.11) with ESMTP id l3BA0paI014730; Wed, 11 Apr 2007 03:00:51 -0700 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 l3BA0oA8007417; Wed, 11 Apr 2007 10:00:51 GMT 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); Wed, 11 Apr 2007 03:00:50 -0700 Received: from [192.168.0.4] ([10.21.90.45]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 03:00:49 -0700 In-Reply-To: <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 03:00:55 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Apr 2007 10:00:49.0925 (UTC) FILETIME=[486D0350:01C77C20] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1241; t=1176285651; x=1177149651; 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=20DNS=20ALG=20(was=20Re=3A=20[RAM]=20Incremental=20Depl oyment=20of=20LISP |Sender:=20; bh=53JvgbB/qDVAdFIKL/eL/0rgODYwm0+nMFE9hxWfZMI=; b=KWrYUT8rpJRZs+NkF1bEa+9m593DIGRZoSwQuW3w7lzJicq1Xw/S+oz95hApJmxuLbFB4FzP 3WLKJkdkEPfjytkBoaZBDL8tEkGdAk7xz44PU9MVLRXCFIzyvXrJOvBL; 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: 93238566e09e6e262849b4f805833007 Cc: Tony Li , "Templin, Fred L" , 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 > So, i would say that one option to get rid of PA addresses is just > to avoid having them present in the intra domain Well the thought for LISP was to have the ETRs be the only routers in the domain to have global routable PA addresses assigned to their loopback interfaces. All other interface addresses can be link-local (for IPv6) or private addresses (for IPv4). With the added benefit of protecting your router resources at your site because they are not routable (so no one from outside can direct packets to them). The same would be true if you used PI addresses at the site which were not injected into the BGP core (not routable). And actually, as deployed today, the ETR addresses that are part of PA space could be the only locators advertised in the core today and all other PA addresses from the course block *would not* have to be advertised. So if you advertise a single /24 today into the core, you *could* instead advertise a single /30 and protect your other routers the same you would do with the above two other addressing cases. The ISP aggregation of such site blocks would not have to change. Comments about this to the operators lurking in on this list? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 06:28:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hba37-0008Bx-QV; Wed, 11 Apr 2007 06:27:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hba34-0008AI-Nk for ram@iab.org; Wed, 11 Apr 2007 06:27:34 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbZyg-0008Cd-Bf for ram@iab.org; Wed, 11 Apr 2007 06:23:06 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 3192717953F; Wed, 11 Apr 2007 12:22:59 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id CE23F17937D; Wed, 11 Apr 2007 12:22:58 +0200 (CEST) In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 12:22:59 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Tony Li , "Templin, Fred L" , 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 El 11/04/2007, a las 12:00, Dino Farinacci escribi=F3: >> So, i would say that one option to get rid of PA addresses is just to=20= >> avoid having them present in the intra domain > > Well the thought for LISP was to have the ETRs be the only routers in=20= > the domain to have global routable PA addresses assigned to their=20 > loopback interfaces. yes i like this clean separation i would like to explore more what are the results of taking this=20 approach of leaving the PA (topology dependent) addresses outside the=20 site > All other interface addresses can be link-local (for IPv6) or even better ULAs (i guess they were defined for that) > or private addresses (for IPv4). With the added benefit of protecting=20= > your router resources at your site because they are not routable (so=20= > no one from outside can direct packets to them). > > The same would be true if you used PI addresses at the site which were=20= > not injected into the BGP core (not routable). > > And actually, as deployed today, the ETR addresses that are part of PA=20= > space could be the only locators advertised in the core today and all=20= > other PA addresses from the course block *would not* have to be=20 > advertised. So if you advertise a single /24 today into the core, you=20= > *could* instead advertise a single /30 and protect your other routers=20= > the same you would do with the above two other addressing cases. The=20= > ISP aggregation of such site blocks would not have to change. > agree with this approach regards, marcelo > Comments about this to the operators lurking in on this list? > > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 06:47:57 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbaL5-0008Kd-Tz; Wed, 11 Apr 2007 06:46:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbaL4-0008KW-LB for ram@iab.org; Wed, 11 Apr 2007 06:46:10 -0400 Received: from mtagate8.de.ibm.com ([195.212.29.157]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbaKo-0004dp-0N for ram@iab.org; Wed, 11 Apr 2007 06:46:10 -0400 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 l3BAjqeV278798 for ; Wed, 11 Apr 2007 10:45:52 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3BAjqDR4022500 for ; Wed, 11 Apr 2007 12:45:52 +0200 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3BAjqZX005056 for ; Wed, 11 Apr 2007 12:45:52 +0200 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3BAjp9c005050; Wed, 11 Apr 2007 12:45:51 +0200 Received: from [9.4.210.149] ([9.4.210.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id MAA352792; Wed, 11 Apr 2007 12:45:47 +0200 Message-ID: <461CBC60.6020308@zurich.ibm.com> Date: Wed, 11 Apr 2007 12:45:52 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP References: <20070329192859.4630E87323@mercury.lcs.mit.edu><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: Tony Li , "Templin, Fred L" , 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 >> All other interface addresses can be link-local (for IPv6) > > or even better ULAs (i guess they were defined for that) Definitely. That way they can be used in site-wide MIBs and config scripts (and there is no pesky id-loc split for site operations people to be confused by). Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 12:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbfnE-000506-SZ; Wed, 11 Apr 2007 12:35:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbfnC-0004z4-LO for ram@iab.org; Wed, 11 Apr 2007 12:35:34 -0400 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 1Hbfn9-0003C4-BT for ram@iab.org; Wed, 11 Apr 2007 12:35:34 -0400 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 l3BGZRdT021558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 09:35:28 -0700 (PDT) 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 l3BGZRXd010902; Wed, 11 Apr 2007 09:35:27 -0700 (PDT) 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 l3BGZKQU010569; Wed, 11 Apr 2007 09:35:20 -0700 (PDT) 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, 11 Apr 2007 09:35:16 -0700 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 09:35:16 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <461C8C4A.8050102@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd8Cerovl8IsorBS+6Ins73Ld1v/wATRGFQ References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> From: "Templin, Fred L" To: "Brian E Carpenter" X-OriginalArrivalTime: 11 Apr 2007 16:35:16.0905 (UTC) FILETIME=[630B9190:01C77C57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Brian, > > No; it is a router-based solution. That the router may > > connect *very* closely to the end host is immaterial, > > and AFAICT incremental deployment is already underway... >=20 > One of the trickiest problems we saw in the shim6 variant > of this is exit router selection, when different routers > are connected to different ISPs. That breaks any 1:1 > relationship between hosts and exit routers, and pretty > much requires some additional mechanism. Isn't this pretty much the same issue as what if there are multiple NATs and/or multiple stateful firewalls at the site border? The issue then becomes one of how to coordinate the stateful site border devices, since state has to be shared among them. Is this a solved problem? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 12:38:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbfno-0005Pt-FC; Wed, 11 Apr 2007 12:36:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbfno-0005Po-0C for ram@iab.org; Wed, 11 Apr 2007 12:36:12 -0400 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 1Hbfnl-0003Jt-P9 for ram@iab.org; Wed, 11 Apr 2007 12:36:11 -0400 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 l3BGa7ge026248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 11:36:08 -0500 (CDT) 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 l3BGa67J012395; Wed, 11 Apr 2007 09:36:06 -0700 (PDT) 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 l3BGa2XR012291; Wed, 11 Apr 2007 09:36:06 -0700 (PDT) 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, 11 Apr 2007 09:36:06 -0700 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 09:36:05 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D2@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd8IEnfDyT2i5QhTcOqBE/b6tYHCgANfmmg References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> From: "Templin, Fred L" To: "Dino Farinacci" , "marcelo bagnulo braun" X-OriginalArrivalTime: 11 Apr 2007 16:36:06.0453 (UTC) FILETIME=[8093FE50:01C77C57] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Tony Li , 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 > > So, i would say that one option to get rid of PA addresses is just =20 > > to avoid having them present in the intra domain >=20 > Well the thought for LISP was to have the ETRs be the only=20 > routers in =20 > the domain to have global routable PA addresses assigned to their =20 > loopback interfaces. All other interface addresses can be link-local =20 > (for IPv6) or private addresses (for IPv4). =20 Sounds like there is some agreement here, and the same is true for ISATAP and IPvLX also. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 12:47:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbfy5-0002LG-Il; Wed, 11 Apr 2007 12:46:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbfy3-0002L8-Nz for ram@iab.org; Wed, 11 Apr 2007 12:46:47 -0400 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 1Hbfy2-0005ev-79 for ram@iab.org; Wed, 11 Apr 2007 12:46:47 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3BGkU9t029312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 09:46:39 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3BGkTbj029071; Wed, 11 Apr 2007 11:46:29 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3BGkJT3028720; Wed, 11 Apr 2007 11:46:27 -0500 (CDT) 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, 11 Apr 2007 09:46:26 -0700 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] LISP etc. is not the only path to scalable routing Date: Wed, 11 Apr 2007 09:46:25 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D3@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <461C6F0B.7000901@firstpr.com.au> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] LISP etc. is not the only path to scalable routing Thread-Index: Acd7+NoWpiK9HCrwTlWv2l9NGZwKGAAX1G6w References: DEFANGED[2851]:DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing. " " com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> <46139B56.5000202@zurich.ibm.com><461A33AE.7090508@firstpr.com.au> <461B7EB5.2010707@zurich.ibm.com> <461C6F0B.7000901@firstpr.com.au> From: "Templin, Fred L" To: "Robin Whittle" , X-OriginalArrivalTime: 11 Apr 2007 16:46:26.0617 (UTC) FILETIME=[F2398290:01C77C58] X-Spam-Score: 0.0 (/) X-Scan-Signature: f49c97ce49302a02285a2d36a99eef8c 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 Robin, I may be speaking outside my area of expertise, but why must LISP-like solutions and more robust core routers be seen as mutually exclusive? Why not have it such that we leave the core as IPv4 and build IPv6 out at the edges. That way, the core is still going to grow and probably need the more robust routers, but there will be a hard upper limit to the growth. Meanwhile, the number of interconnected IPv6 devices at the edges could scale to virtually limitless proportions while the core remains manageable. Am I making any sense here? Fred fred.l.templin@boeing.com=20 > -----Original Message----- > From: Robin Whittle [mailto:rw@firstpr.com.au]=20 > Sent: Tuesday, April 10, 2007 10:16 PM > To: ram@iab.org > Subject: Re: [RAM] LISP etc. is not the only path to scalable routing >=20 > Hi Brian, >=20 > I accept that the most administratively simple approach to address > assignment is for an ISP or AS end-user organisation to get a single > block of address space which is big enough to suit its greatest > possible needs for the next decade or two. >=20 > The two reasons for providing such a large, single, long-lasting > block seem to be this administrative simplicity and the desire for > route aggregation. >=20 > Most users of an address block such as this will want to split it > geographically for its various branch offices, and for each office > (or even for a small organisation with a single site) to split it > and advertise it on topologically diverse parts of the Net. The > more topologically diverse, the better, in terms of providing robust > multihoming. So I think the goal of assigning larger blocks less > frequently for the purpose of preserving route aggregation is > illusory. >=20 > This leaves the other goal of administrative simplicity for each > medium to large organisation. I assume that small organisations > with a single site could get by with a single assignment for quite a > number of years - for instance a /22 to /24which they can advertise > as one or more separate/24s for multihoming. There is also the goal > of administrative simplicity for RIRs handing out a large block at > one time rather than a lot of smaller blocks more frequently. >=20 > The trouble is with the traditional approach to address assignment > is that really large slabs of address space are assigned, with > generally minimal utilisation - with the result that we are running > out of fresh address space. Then everyone has to adopt LISP or > IPv6, both of which have a bunch of costs and problems. >=20 > I don't think that the immense global, shared, cost of: >=20 > 1 - Being forced into IPv6 just due to shortage of fresh address > space in IPv4. >=20 > or >=20 > 2 - Having to pay for massive TCAM in all DFZ routers. >=20 > or >=20 > 3 - Having to change IPv4 usage such as with LISP, including new > routers all over the edge of the network, and a large > subset of address space being excluded from being the > BGP routing system. >=20 > is justified by the administrative simplicity of medium and larger > users having a single slab of addresses, compared to them getting > multiple smaller blocks as they need them and the deployment of a > new generation of SRAM-based DFZ routers. >=20 > I think we may be able to avoid 2 and 3 above, and not be forced > into IPv6 for another decade or more, if the IPv4 address space is > used much more efficiently. To do this, it needs to be sliced and > diced with freedom. In the past, routers couldn't be built to > handle this. Now I believe they can. >=20 > For my suggestion to be practical, there needs to be more CPU power > and RAM in the DFZ routers and the changes in BGP advertised > prefixes probably need to be restricted to long-term changes > reflecting basic network topology and to short-term changes due to > genuine outages. I do not propose the global BGP system be loaded > down by some prefixes being changed for short-term, recurring > purposes, such as adapting to daily changes in traffic patterns. >=20 > Since the DFZ routers will all be replaced in 5 years or less, I > suggest the new ones be equipped with SRAM so they easily route (or > perhaps switch) packets to 14.5 million freely assignable IPv4 /24 > prefixes. This should require minimal incremental expense in the > DFZ, which all Net users share. It requires no expenditure on LISP > routers in provider and AS end-user networks. It requires no > inefficient headers, new protocols or centralised mapping databases. >=20 > I think these aspects of LISP, including - as best I can understand > - the need (with LISP 1.5+) to remove a substantial proportion of > the address space from the global BGP system and handle it with > LISP, would be more administratively complex than medium to large > organisations having to get address space in smaller, > non-contiguous, chunks. >=20 >=20 > - Robin >=20 >=20 > > Robin, > > > >> What my SRAM proposal needs is a more compact handling of the > >> bits 124 to, for instance 92 (a /35 prefix). This will feel > >> really bad to anyone who feels good about vast expanses of > >> address space, for instance on the basis that a single prefix > >> will last an organisation for decades, no matter how much it > >> expands. But that feeling isn't necessary in a flat routing > >> model, because each AS end-user or ISP can easily get more space, > >> non-contiguously, as they need it. > > > > You missed my point. Enterprise network managers design > > addressing plans that covers perhaps hundreds of sites with tens > > of LANs each. They are not interested in acquiring scraps of > > address space each time they need some more. This is nothing to do > > with flat routing; even the largest enterprise networks can easily > > be flat routed. > > It's to do with administrative simplicity. > > > > Brian >=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 Wed Apr 11 12:56:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbg7U-0007ga-21; Wed, 11 Apr 2007 12:56:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbg7S-0007gS-Nh for ram@iab.org; Wed, 11 Apr 2007 12:56:30 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbg7Q-0000CE-94 for ram@iab.org; Wed, 11 Apr 2007 12:56:30 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5A83917A319; Wed, 11 Apr 2007 18:56:27 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id 3F31517A308; Wed, 11 Apr 2007 18:56:27 +0200 (CEST) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 18:56:26 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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 El 11/04/2007, a las 18:35, Templin, Fred L escribi=F3: > Brian, > >>> No; it is a router-based solution. That the router may >>> connect *very* closely to the end host is immaterial, >>> and AFAICT incremental deployment is already underway... >> >> One of the trickiest problems we saw in the shim6 variant >> of this is exit router selection, when different routers >> are connected to different ISPs. That breaks any 1:1 >> relationship between hosts and exit routers, and pretty >> much requires some additional mechanism. > > Isn't this pretty much the same issue as what if there are > multiple NATs and/or multiple stateful firewalls at the site > border? The issue then becomes one of how to coordinate the > stateful site border devices, since state has to be shared > among them. > i guess that the difference here is that we are actually designing a=20 fault tolerance solution, so it is a non starter if you introduce a=20 single point of failure, meaning that any solution must provide this=20 capability from the start (which is not the case of NAT and firewalls) > Is this a solved problem? > I have tried to provide such support in the proxy-shim6 approach, but=20 it does introduce additional complexity In particular, you need to be capable of restoring the ID to locator=20 mapping information in the backup box, which implies or either that you=20= distribute the id loc mapping information about all ongoing=20 communications from the primary box to all backup boxes when the=20 communication starts or that you have a mechanism to restore such=20 information when the primary is down. Such mechanism for restoring the=20= information should provide the means to retrieve the locators=20 associated to the destiantion identifier Regards, marcelo > Fred > fred.l.templin@boeing.com > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 13:15:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbgP0-0008I1-B7; Wed, 11 Apr 2007 13:14:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbgOy-0008Hp-Jc for ram@iab.org; Wed, 11 Apr 2007 13:14:36 -0400 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 1HbgOx-0006ow-Ad for ram@iab.org; Wed, 11 Apr 2007 13:14:36 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3BHEYO5022953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 12:14:34 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3BHEXtw027340; Wed, 11 Apr 2007 12:14:33 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3BHEWLU027293; Wed, 11 Apr 2007 12:14:33 -0500 (CDT) 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, 11 Apr 2007 10:14:29 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 10:14:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D4@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd8Wlo6FygYtsYKSo6DdK+Tk1vHdQAAG2zw References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 11 Apr 2007 17:14:29.0420 (UTC) FILETIME=[DD40DEC0:01C77C5C] X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 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 Comment inline below:=20 > -----Original Message----- > From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es]=20 > Sent: Wednesday, April 11, 2007 9:56 AM > To: Templin, Fred L > Cc: Brian E Carpenter; ram@iab.org > Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP >=20 >=20 > El 11/04/2007, a las 18:35, Templin, Fred L escribi=F3: >=20 > > Brian, > > > >>> No; it is a router-based solution. That the router may > >>> connect *very* closely to the end host is immaterial, > >>> and AFAICT incremental deployment is already underway... > >> > >> One of the trickiest problems we saw in the shim6 variant > >> of this is exit router selection, when different routers > >> are connected to different ISPs. That breaks any 1:1 > >> relationship between hosts and exit routers, and pretty > >> much requires some additional mechanism. > > > > Isn't this pretty much the same issue as what if there are > > multiple NATs and/or multiple stateful firewalls at the site > > border? The issue then becomes one of how to coordinate the > > stateful site border devices, since state has to be shared > > among them. > > >=20 > i guess that the difference here is that we are actually designing a=20 > fault tolerance solution, so it is a non starter if you introduce a=20 > single point of failure, meaning that any solution must provide this=20 > capability from the start (which is not the case of NAT and firewalls) But, the further out toward the edges we locate the ITR the more it becomes a fate-sharing situation, e.g., the ITR is available IFF the physical platform itself is still intact. The physical platform could then still be multihomed (perhaps even to many different providers) but the appearance to nodes on the inside looking for a way out would be as a single ITR. =20 > > Is this a solved problem? > > >=20 > I have tried to provide such support in the proxy-shim6 approach, but=20 > it does introduce additional complexity >=20 > In particular, you need to be capable of restoring the ID to locator=20 > mapping information in the backup box, which implies or=20 > either that you=20 > distribute the id loc mapping information about all ongoing=20 > communications from the primary box to all backup boxes when the=20 > communication starts or that you have a mechanism to restore such=20 > information when the primary is down. Such mechanism for=20 > restoring the=20 > information should provide the means to retrieve the locators=20 > associated to the destiantion identifier If there is no way to ensure that the host will always stick with the same ITR (which I'm not yet convinced of), then it would have to be something like a site-local resolution service keyed off the destination IP address, right? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 15:20:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbiLT-0002j9-Q6; Wed, 11 Apr 2007 15:19:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbiLR-0002hJ-Pt for ram@iab.org; Wed, 11 Apr 2007 15:19:05 -0400 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 1HbiLP-0000d3-4Z for ram@iab.org; Wed, 11 Apr 2007 15:19:05 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 11 Apr 2007 12:19:02 -0700 X-IronPort-AV: i="4.14,395,1170662400"; d="scan'208"; a="477541333:sNHT56053828" 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 l3BJJ192032020; Wed, 11 Apr 2007 12:19:01 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3BJImZr004452; Wed, 11 Apr 2007 19:18:56 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 12:18:39 -0700 Received: from [192.168.0.4] ([10.21.80.32]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Apr 2007 12:18:38 -0700 In-Reply-To: <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> 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: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 12:18:45 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 11 Apr 2007 19:18:38.0603 (UTC) FILETIME=[354FFDB0:01C77C6E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5174; t=1176319141; x=1177183141; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=zLIAMkgIPcGt67guSmSeL5KTP1iUPVAuIe8qDtMGd90=; b=AQzK6ncJ4y9tCAc6i9NUaTFu/ri2v22mMo/paXKGHshEWwdV60eJcJfeClhv4kT2hTlTHDr3 pVpcxIxC3EaVDMLC/RFWVo+N11fHFWIQyUNZPrl+J6W38qXH4WIWKLoc; 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: 5d7a7e767f20255fce80fa0b77fb2433 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 > so are you envisioning an hybrid system that has both the push and > pull models? In such scheme there would be these mesh of high level > routers that exchange the whole loc id mapping database and then > smaller routers that use the pull model to query these high level > routers? Yes, I think something like that. > the new protocol would then run between these high level routers, > is that it? Yes, which will be trusted. As well as having a registration procedure that is pub/priv key protected for the ETRs to register EID- to-RLOC mappings. I think we have a good demarcation design where the LISP-00 ID can use various means to obtain the mappings. I can see any or all of the following: o Static o ICMP o DNS o Push-only o Push-n-pull o Pull with new database We can try them all out and start pruning what we think we don't like. But the pruning happens after *implementation*. That is we obtain rough consensus and running code. ;-) I think I heard that once before. ;-) It would be really nice if folks on this list could pick one to focus on. You can use me as a focal point so we don't duplicate effort. Whadaya think? > I am not saying to use the BGP instance used today to exchange > routing information to also exchange loc/id mapping information. Yes, I understood what you said. And I realize this new instance would carry less stuff. > What i am saying is using the BGP protocol for that, meaning to > create a _new_ instance of BGP and run it for instance between the > high level routers that you mention above. In this case, these high > level routers would run two instances of BGP. On instance of BGP, > that would distribute routing information as it is done today. > Another instance of BGP would be used to distribute the id loc > mapping information Yes, and there could be a good possibility that any given router may not run both instances. We might want to make that a goal. Definitely at the high-level system deployment (note I didn't say routers, because we could have low-cost, fast, linux systems do this). >>> do you think that BGP is lacking some of the required capabilities? >> >> Yep. Plus it has more than we want. And many have shown that BGP >> is not an efficient flooding protocol. >> > > i don't know about that... i mean, BGP as a protocol seems to be > quite simple and eficient and it is already out there We would have to turn off best-path selection. Many attributes wouldn't apply to this new NLRI type, etc. > I mean, i do agree that BGP does provide some features that may not > be needed for an id loc mapping protocol, but i am not sure this > outwiegths the benefits of being a protocol already available in > deployed routers Marcelo, I think it's definitely something to consider. I don't want to give the wrong impression I'm against BGP. >>> note that for globally distributing the ID to locator mapping >>> information, you would just need to enable another instance of >>> BGP with maybe some extensions, that would >> >> That was a possibility we considered with LISP 1.5. > > i don't think this is similar than LISP 1.5, please see below... I know, because we wouldn't be routing EIDs. But if we didn't want to drop packets in the ITR, the ITR could encapsulate to one of the high- level routers that would have the mapping and then it would "re- encapsulate" (versus recursive encapsulate as the LISP ID states) to the site's ETR. This increases stretch that we *could* stick with, or the ETR could send the mapping to the ITR via an ICMP EID-to-RLOC Reply. I really think we have a lot of options (maybe too many ;-)). > I am not saying to overload BGP with additional information, but to > run a different instance of BGP to distribute other information. It > is similar to the considerations being made about the differences > between the DNS protocol and the DNS system. I am not proposing to > use current BGP system (the instace of BGP used to currently > distribute routing information) but to build another instance of > the BGP protocol to distribute the id loc mapping information. Re > use the BGP protocol not the current BGP routing system Yes, understand. Lixia made the same suggestion using the DNS protocol. That is use DNS the protocol as your query/reply protocol but don't run it on UDP 53. But I have to beg the question, why people think this is the long pole in the tent? That is designing a straight-forward protocol shouldn't be hard or time consuming. > policy seems to be one of the key features that are missing in > available solutions, so i would put quite some focus on that Well I was thinking of access control. But in terms of locator selection, that is where I think there needs to be focus. Can you tell me if what LISP proposes with using priorities and weights per locator is not sufficient. It should be familiar to you. ;-) And I did run it by both large-site enterprise types and ISP types. Thanks, Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 11 16:12:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjAR-0004Mw-JX; Wed, 11 Apr 2007 16:11:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbjAQ-0004Mb-O6 for ram@iab.org; Wed, 11 Apr 2007 16:11:46 -0400 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 1HbjAM-0000xc-Ow for ram@iab.org; Wed, 11 Apr 2007 16:11:46 -0400 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 l3BKBc2L020888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 11 Apr 2007 13:11:39 -0700 (PDT) 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 l3BKBcft027812; Wed, 11 Apr 2007 13:11:38 -0700 (PDT) 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 l3BKBVi8027577; Wed, 11 Apr 2007 13:11:35 -0700 (PDT) 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, 11 Apr 2007 13:11:34 -0700 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: ID/loc mapping distribution protocol (was Re: [RAM] IncrementalDeployment of LISP Date: Wed, 11 Apr 2007 13:11:33 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D7@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ID/loc mapping distribution protocol (was Re: [RAM] IncrementalDeployment of LISP Thread-Index: Acd8bnNVgVGc7EB8Q6GRK0JuwXBHjQABlRZw References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net><41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es><979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com><922351a8b609dc4cf2072fd878b609cb@it.uc3m.es><816668963e0ee48143c31b9006c551d0@it.uc3m.es><0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com><0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> From: "Templin, Fred L" To: "Dino Farinacci" , "marcelo bagnulo braun" X-OriginalArrivalTime: 11 Apr 2007 20:11:34.0743 (UTC) FILETIME=[9A707E70:01C77C75] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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, =20 > It would be really nice if folks on this list could pick one=20 > to focus on. Earlier on, you seemed skeptical of DNS but so far that seems to be the one folks are most interested in discussing. DNS+static should also be considered, though, since resolvers can be pre-populated by network management, manual config, etc. (Oh - and, please don't forget IPvLX.) Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 00:06:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbqZo-0000sI-Vn; Thu, 12 Apr 2007 00:06:28 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbqZn-0000rm-0K for ram@iab.org; Thu, 12 Apr 2007 00:06:27 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbqZk-0004kP-5r for ram@iab.org; Thu, 12 Apr 2007 00:06:26 -0400 Received: from [192.168.0.16] (c24-143-71-81.sea2.cablespeed.com [24.143.71.81] (may be forged)) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l3C44wma015307 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Thu, 12 Apr 2007 00:06:15 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F-BC5F-947E0BD4594C@cisco.com> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <558071D3-41B4-4362-A984-44361175427B@lugs.com> Content-Transfer-Encoding: 7bit From: Peter Schoenmaker Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 20:01:12 -0400 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Thu, 12 Apr 2007 00:06:17 -0400 (EDT) X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: Tony Li , "Templin, Fred L" , 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 Apr 11, 2007, at 6:00 AM, Dino Farinacci wrote: >> So, i would say that one option to get rid of PA addresses is just >> to avoid having them present in the intra domain > > Well the thought for LISP was to have the ETRs be the only routers > in the domain to have global routable PA addresses assigned to > their loopback interfaces. All other interface addresses can be > link-local (for IPv6) or private addresses (for IPv4). With the > added benefit of protecting your router resources at your site > because they are not routable (so no one from outside can direct > packets to them). > > The same would be true if you used PI addresses at the site which > were not injected into the BGP core (not routable). > > And actually, as deployed today, the ETR addresses that are part of > PA space could be the only locators advertised in the core today > and all other PA addresses from the course block *would not* have > to be advertised. So if you advertise a single /24 today into the > core, you *could* instead advertise a single /30 and protect your > other routers the same you would do with the above two other > addressing cases. The ISP aggregation of such site blocks would not > have to change. > > Comments about this to the operators lurking in on this list? I hope ultimately customers use PI addresses that are not injected into the BGP core. This seems like the ultimate solution, to give every host a unique identifier. link-local/private addresses are only an interim step. peter > > 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 Thu Apr 12 01:00:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbrPa-0003FO-Fm; Thu, 12 Apr 2007 00:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbrPZ-0003FJ-Hg for ram@iab.org; Thu, 12 Apr 2007 00:59:57 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbrPY-0006TT-6M for ram@iab.org; Thu, 12 Apr 2007 00:59:57 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2007 06:59:56 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3C4xtms008602; Thu, 12 Apr 2007 06:59:55 +0200 Received: from xbh-ams-331.emea.cisco.com (xbh-ams-331.cisco.com [144.254.231.71]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3C4xslZ012486; Thu, 12 Apr 2007 04:59:55 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-331.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 06:59:52 +0200 Received: from [192.168.0.4] ([10.21.123.129]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 06:59:51 +0200 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D7@XCH-NW-7V2.nw.nos.boeing.com> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net><41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es><979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com><922351a8b609dc4cf2072fd878b609cb@it.uc3m.es><816668963e0ee48143c31b9006c551d0@it.uc3m.es><0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com><0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D7@XCH-NW-7V2.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: <51A186FC-D3D5-4196-93FA-6E9202A68CD4@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] IncrementalDeployment of LISP Date: Wed, 11 Apr 2007 15:08:08 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Apr 2007 04:59:51.0411 (UTC) FILETIME=[67203430:01C77CBF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1669; t=1176353995; x=1177217995; c=relaxed/simple; s=amsdkim1002; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20IncrementalDeployment=20of=20LISP |Sender:=20; bh=1e9i3wSCaez8W52Z6Pr0HrxSi1olBHniI2z29ngud58=; b=T5565/NjwFwDiSnS4y7pgs6d/j1ezKzvfqfRyIz7hHGnmRNU5Ug+X3016465aTg9igcKAYSg 4flkxhfIvhCgcYswo1PdcS6e+n++bQCSSIVLp7bfZ5tT9LmSxNz/c/Fv; Authentication-Results: ams-dkim-1; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 would be really nice if folks on this list could pick one >> to focus on. > > Earlier on, you seemed skeptical of DNS but so far that > seems to be the one folks are most interested in discussing. > DNS+static should also be considered, though, since resolvers > can be pre-populated by network management, manual config, etc. > (Oh - and, please don't forget IPvLX.) I still think it is not architecturally good from for routing to depend on DNS-53. That is, adding new RR records to the existing DNS infrastructure to support a Loc/ID split. Plus, you will need to secure EID-to-RLOC mappings. The DNSSEC RFC indicates that KEY RR records are for securing DNS proper and not for securing other protocols. Using DNS as a request/reply protocol is fine. But there isn't much to it and we could do our own request/reply protocol. To follow your line of thinking, which has been suggested by a few folks is to: o Point hosts to routers who are DNS-53 servers. o When the A record reply is returned to the router, it can use the A record as an EID query to another database. o When the RLOC comes back, the router returns the DNS response to the host. o The host emits packet to A record, the router has mapping for it and can encapsulate to the RLOC. But not everything uses DNS! Don't forget SIP, don't forget debug tools people use with IP and IPv6 addresses only and no names. So I wouldn't want to have a mechanism for every type of application directory service we have. Other examples of directory services is AIM, Skype, and BitTorrent, which are very application specific. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 01:00:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbrQJ-0003Re-VN; Thu, 12 Apr 2007 01:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbrQI-0003O2-89 for ram@iab.org; Thu, 12 Apr 2007 01:00:42 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbrQG-0006fi-UW for ram@iab.org; Thu, 12 Apr 2007 01:00:42 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 12 Apr 2007 07:00:41 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3C50ewq030489; Thu, 12 Apr 2007 07:00:40 +0200 Received: from xbh-ams-332.emea.cisco.com (xbh-ams-332.cisco.com [144.254.231.87]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3C50elZ012724; Thu, 12 Apr 2007 05:00:40 GMT Received: from xfe-ams-332.cisco.com ([144.254.231.73]) by xbh-ams-332.emea.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 07:00:40 +0200 Received: from [192.168.0.4] ([10.21.123.129]) by xfe-ams-332.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 07:00:39 +0200 In-Reply-To: References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.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: <6FD29B3B-2949-4030-B7C0-2B1097D54F36@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Wed, 11 Apr 2007 15:18:46 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 12 Apr 2007 05:00:39.0862 (UTC) FILETIME=[84013D60:01C77CBF] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=925; t=1176354040; x=1177218040; c=relaxed/simple; s=amsdkim2001; 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=20DNS=20ALG=20(was=20Re=3A=20[RAM]=20Incremental=20Depl oyment=20of=20LISP |Sender:=20; bh=F9AxLf4WHlrptH+JKxDzpH6zedYhV7VP+EZ8C3RG/ig=; b=peniC53ixYUIlK2Bj18I2wdJAK0iFI7TsdoSNtI0WWcLWQevIcEijzGlR9v/FVwZFjCN5rKd c6KRca72u8ClVhyiF4Jkhc3vZVwBRx65GT+jdAAiIMWlTndETOp+0MDT; Authentication-Results: ams-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.2 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: "Templin, Fred L" , 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 particular, you need to be capable of restoring the ID to > locator mapping information in the backup box, which implies or > either that you distribute the id loc mapping information about all > ongoing communications from the primary box to all backup boxes > when the communication starts or that you have a mechanism to > restore such information when the primary is down. Such mechanism > for restoring the information should provide the means to retrieve > the locators associated to the destiantion identifier The way we spec'ed this in the LISP draft is to have both ETRs configure the IP addresses of all loopback addresses among them. So a packet that enters one of them can respond with an ICMP reply for all locators. On packet egress from the site, the chosen exit ITR would do the mapping independently of the other. So there is no need for synchronization. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 01:22:21 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbrl2-00061Z-Dz; Thu, 12 Apr 2007 01:22:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbrl1-00061U-3u for ram@iab.org; Thu, 12 Apr 2007 01:22:07 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbrkx-0004o7-LC for ram@iab.org; Thu, 12 Apr 2007 01:22:07 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 2F29559E53; Thu, 12 Apr 2007 15:22:01 +1000 (EST) Message-ID: <461DC1EE.40406@firstpr.com.au> Date: Thu, 12 Apr 2007 15:21:50 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] LISP etc. is not the only path to scalable routing References: DEFANGED[2851]:DEFANGED[152]:<474EEBD229DF754FB83D256004D0210802584EA6@XCH-NW-6V1.nw.nos.boeing.com><22000.61535.qm@web58714.mail.re1.yahoo.com><474EEBD229DF754FB83D256004D0210802584EA8@XCH-NW-6V1.nw.nos.boeing. " " com><474EEBD22 " " 9DF754FB83D256004D0210802584EA9@XCH-NW-6V1.nw.nos.boeing.com> <474EEBD229DF754FB83D256004D0210802584EAE@XCH-NW-6V1.nw.nos.boeing.com> <4611BC16.7090904@firstpr.com.au> <6A880300-7B5E-47A3-94EA-1A0160110FE5@virtualized.org> <461335F1.8020908@firstpr.com.au> <46139B56.5000202@zurich.ibm.com><461A33AE.7090508@firstpr.com.au> <461B7EB5.2010707@zurich.ibm.com> <461C6F0B.7000901@firstpr.com.au> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D3@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D3@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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 Fred, I am working on a longer message contemplating how LISP and SRAM-based forwarding might complement each other. - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 05:29:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvaY-0003hR-K8; Thu, 12 Apr 2007 05:27:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbvaX-0003hM-Fr for ram@iab.org; Thu, 12 Apr 2007 05:27:33 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbvaX-0001pH-01 for ram@iab.org; Thu, 12 Apr 2007 05:27:33 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id ED3D3C0A77; Thu, 12 Apr 2007 11:27:31 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 545CCC0A20; Thu, 12 Apr 2007 11:27:31 +0200 (CEST) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D4@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> <39C 363776A4E8C4A94691D2BD9D1C9A1029ED6D4@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Thu, 12 Apr 2007 11:27:30 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 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 El 11/04/2007, a las 19:14, Templin, Fred L escribi=F3: > Comment inline below: > >> -----Original Message----- >> From: marcelo bagnulo braun [mailto:marcelo@it.uc3m.es] >> Sent: Wednesday, April 11, 2007 9:56 AM >> To: Templin, Fred L >> Cc: Brian E Carpenter; ram@iab.org >> Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP >> >> >> El 11/04/2007, a las 18:35, Templin, Fred L escribi=F3: >> >>> Brian, >>> >>>>> No; it is a router-based solution. That the router may >>>>> connect *very* closely to the end host is immaterial, >>>>> and AFAICT incremental deployment is already underway... >>>> >>>> One of the trickiest problems we saw in the shim6 variant >>>> of this is exit router selection, when different routers >>>> are connected to different ISPs. That breaks any 1:1 >>>> relationship between hosts and exit routers, and pretty >>>> much requires some additional mechanism. >>> >>> Isn't this pretty much the same issue as what if there are >>> multiple NATs and/or multiple stateful firewalls at the site >>> border? The issue then becomes one of how to coordinate the >>> stateful site border devices, since state has to be shared >>> among them. >>> >> >> i guess that the difference here is that we are actually designing a >> fault tolerance solution, so it is a non starter if you introduce a >> single point of failure, meaning that any solution must provide this >> capability from the start (which is not the case of NAT and = firewalls) > > But, the further out toward the edges we locate the ITR the > more it becomes a fate-sharing situation, e.g., the ITR is > available IFF the physical platform itself is still intact. > The physical platform could then still be multihomed (perhaps > even to many different providers) but the appearance to nodes > on the inside looking for a way out would be as a single ITR. > i am not following you... The whole point of a multihoming solution is to be able to connect to=20 multiple providers and provide fault tolerance. The actual difficullt=20 part is to preserve established communications after an outage, when a=20= different ISP is used So i don't think we are in a fate sharing situation actually, i would expect that in a site/platform there will be multiple=20= ITRs connecting to different ISPs and that communication must be=20 preserved if the ITR used for the communication goes down and the=20 communication is rerouted through an alternative ITR and ISP I think that any solution must not introduce any new single point of=20 failures. >>> Is this a solved problem? >>> >> >> I have tried to provide such support in the proxy-shim6 approach, but >> it does introduce additional complexity >> >> In particular, you need to be capable of restoring the ID to locator >> mapping information in the backup box, which implies or >> either that you >> distribute the id loc mapping information about all ongoing >> communications from the primary box to all backup boxes when the >> communication starts or that you have a mechanism to restore such >> information when the primary is down. Such mechanism for >> restoring the >> information should provide the means to retrieve the locators >> associated to the destiantion identifier > > If there is no way to ensure that the host will always stick > with the same ITR (which I'm not yet convinced of), then it > would have to be something like a site-local resolution > service keyed off the destination IP address, right? this in one option, since you need to restore state that was already=20 available in the site, so you can have it replicated at the momento of=20= the creation of the state. the other option is to allow to restore the=20= information retrieving the information from outside the site (from=20 where it came initially) the benefit of the second approach is that if you already need a=20 service to retrieve the ID loc mapping information, you can use it as=20 well to support this, so you don't need additional intra site=20 replicating services/protocols but both approaches are possible, afaict regards, marcelo > > Fred > fred.l.templin@boeing.com > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 06:02:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbw69-0003PB-HC; Thu, 12 Apr 2007 06:00:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hbw66-0003P0-6o for ram@iab.org; Thu, 12 Apr 2007 06:00:10 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hbw65-0002nF-GJ for ram@iab.org; Thu, 12 Apr 2007 06:00:10 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8D90AC055E; Thu, 12 Apr 2007 12:00:08 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 6F1A5C0550; Thu, 12 Apr 2007 12:00:06 +0200 (CEST) In-Reply-To: References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <25ecebd4d02476187199445d63130075@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Thu, 12 Apr 2007 12:00:05 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b 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 El 11/04/2007, a las 21:18, Dino Farinacci escribi=F3: >> so are you envisioning an hybrid system that has both the push and=20 >> pull models? In such scheme there would be these mesh of high level=20= >> routers that exchange the whole loc id mapping database and then=20 >> smaller routers that use the pull model to query these high level=20 >> routers? > > Yes, I think something like that. > >> the new protocol would then run between these high level routers, is=20= >> that it? > > Yes, which will be trusted. As well as having a registration procedure=20= > that is pub/priv key protected for the ETRs to register EID-to-RLOC=20 > mappings. > So are you using a trust model that is based on a closed set of=20 participants that trust each other rather than a mean to certify that=20 the actual information about binding is correct? > I think we have a good demarcation design where the LISP-00 ID can use=20= > various means to obtain the mappings. I can see any or all of the=20 > following: > > o Static i don't think we should preclude this one, but i don't think it is=20 general enough to solve our problems (i would leave it as a corner case=20= for testing and exceptions) > o ICMP My take on this one is that much needs to change from its current form=20= to be secured. In particular you will need a few more message exchange=20= to achieve this. Besides, you need a valid ID to locator mapping (with at least one=20 working locator) to actually send the initial request, so this needs to=20= be complemented with an additional mechanism. In LISP 1, the mechanism=20= is the identity, since the identifier is also a valid locator. In HIP is the DNS, where you can obtain the locators and the identifier=20= from the DNS query (note that this requires a fqdn, since there is no=20 id to locator mapping service) In shim6, is both of them > o DNS not sure what do you mean here... the DNS as used in HIP? i.e. using the DNS to obtain both the=20 identifier and the locator set associated to a fqdn or the DNS system to retrieve identifier to locator mapping, like for=20 instance using ULAs as identifiers and using the DNS reverse tree entry=20= for the ULA for retrieving the locators associated with this=20 identifier? the DNS as a generic protocol independent of the current DNS system to=20= make a directory service for retrieving Id to locator mapping? In any case, in order to answer this question, i guess that an=20 important previous question is how do you think the identifier=20 namespace will be? I mean, it seems that DNS type of approach will not=20= scale to support an 128 bit unstrucutred identifier namespace. OTOH, if=20= you are thinking of using ULAs or PI addresses as identifier, then this=20= may work > o Push-only > o Push-n-pull i like your argument that it is good not to require every ITR to have=20 the full database, even in a push model. I think we should continue=20 exploring this solution space > o Pull with new database > again, i think this is closely related with the characteristics of the=20= identifier namespace. If we have an existnet protocol like the DNS that=20= can provide this feature, i don't see the need for this. > We can try them all out and start pruning what we think we don't like.=20= > But the pruning happens after *implementation*. That is we obtain=20 > rough consensus and running code. ;-) I think I heard that once=20 > before. ;-) > > It would be really nice if folks on this list could pick one to focus=20= > on. You can use me as a focal point so we don't duplicate effort. > > Whadaya think? > ... > >> I mean, i do agree that BGP does provide some features that may not=20= >> be needed for an id loc mapping protocol, but i am not sure this=20 >> outwiegths the benefits of being a protocol already available in=20 >> deployed routers > > Marcelo, I think it's definitely something to consider. I don't want=20= > to give the wrong impression I'm against BGP. > maybe the push and pull approach could be based on BGP+DNS... >>>> note that for globally distributing the ID to locator mapping=20 >>>> information, you would just need to enable another instance of BGP=20= >>>> with maybe some extensions, that would >>> >>> That was a possibility we considered with LISP 1.5. >> >> i don't think this is similar than LISP 1.5, please see below... > > I know, because we wouldn't be routing EIDs. But if we didn't want to=20= > drop packets in the ITR, the ITR could encapsulate to one of the=20 > high-level routers that would have the mapping and then it would=20 > "re-encapsulate" (versus recursive encapsulate as the LISP ID states)=20= > to the site's ETR. > something similar like a default route for EIDs? you may end up with a similar concept of the DFZ but for routers that=20 know how to map identifiers... > This increases stretch that we *could* stick with, or the ETR could=20 > send the mapping to the ITR via an ICMP EID-to-RLOC Reply. > yes, i think this additional stretch could be acceptable for a few=20 initial packets > I really think we have a lot of options (maybe too many ;-)). > >> I am not saying to overload BGP with additional information, but to=20= >> run a different instance of BGP to distribute other information. It=20= >> is similar to the considerations being made about the differences=20 >> between the DNS protocol and the DNS system. I am not proposing to=20 >> use current BGP system (the instace of BGP used to currently=20 >> distribute routing information) but to build another instance of the=20= >> BGP protocol to distribute the id loc mapping information. Re use the=20= >> BGP protocol not the current BGP routing system > > Yes, understand. Lixia made the same suggestion using the DNS=20 > protocol. That is use DNS the protocol as your query/reply protocol=20 > but don't run it on UDP 53. > > But I have to beg the question, why people think this is the long pole=20= > in the tent? That is designing a straight-forward protocol shouldn't=20= > be hard or time consuming. imho, established well known protocols that have already been tested=20 and are stable are better choice than new protocols, that need to=20 mature. Of course, this only if we don't overload existent usages. For=20= that reason, i think that if we can reuse the protocol but maybe not=20 the actual current system, seems the best tradeoff (of course if the=20 protocols do provide the required functionality, which is not at all=20 clear yet) > >> policy seems to be one of the key features that are missing in=20 >> available solutions, so i would put quite some focus on that > > Well I was thinking of access control. But in terms of locator=20 > selection, that is where I think there needs to be focus. Can you tell=20= > me if what LISP proposes with using priorities and weights per locator=20= > is not sufficient. I would like isps and end site users to reply to this i mean having a draft describing the needs in term of policy and TE=20 from mutlihomed end sites and isps would be a great help in order to=20 design a solution that suit their needs... Regards, marcelo > It should be familiar to you. ;-) And I did run it by both=20 > large-site enterprise types and ISP types. > > Thanks, > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 06:08:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwCn-0007Wx-8J; Thu, 12 Apr 2007 06:07:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwCl-0007SJ-R1 for ram@iab.org; Thu, 12 Apr 2007 06:07:03 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbwCl-0004wb-C6 for ram@iab.org; Thu, 12 Apr 2007 06:07:03 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 6BB01C0370; Thu, 12 Apr 2007 12:07:02 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 4D42CC055E; Thu, 12 Apr 2007 12:07:02 +0200 (CEST) In-Reply-To: <51A186FC-D3D5-4196-93FA-6E9202A68CD4@cisco.com> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com><5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net><41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es><979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com><922351a8b609dc4cf2072fd878b609cb@it.uc3m.es><816668963e0ee48143c31b9006c551d0@it.uc3m.es><0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com><0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D7@XCH-NW-7V2.nw.nos.boeing.com> <51A186FC-D3D5-4196-93FA-6E9202A68CD4@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <23cb89ceec10d0498fbfa16c9859ccc4@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] IncrementalDeployment of LISP Date: Thu, 12 Apr 2007 12:07:01 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: "Templin, Fred L" , 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 El 12/04/2007, a las 0:08, Dino Farinacci escribi=F3: >>> It would be really nice if folks on this list could pick one >>> to focus on. >> >> Earlier on, you seemed skeptical of DNS but so far that >> seems to be the one folks are most interested in discussing. >> DNS+static should also be considered, though, since resolvers >> can be pre-populated by network management, manual config, etc. >> (Oh - and, please don't forget IPvLX.) > > I still think it is not architecturally good from for routing to=20 > depend on DNS-53. That is, adding new RR records to the existing DNS=20= > infrastructure to support a Loc/ID split. Plus, you will need to=20 > secure EID-to-RLOC mappings. The DNSSEC RFC indicates that KEY RR=20 > records are for securing DNS proper and not for securing other=20 > protocols. > > Using DNS as a request/reply protocol is fine. But there isn't much to=20= > it and we could do our own request/reply protocol. > > To follow your line of thinking, which has been suggested by a few=20 > folks is to: > > o Point hosts to routers who are DNS-53 servers. > o When the A record reply is returned to the router, it can use the A=20= > record as > an EID query to another database. > o When the RLOC comes back, the router returns the DNS response to the=20= > host. > o The host emits packet to A record, the router has mapping for it and=20= > can > encapsulate to the RLOC. > > But not everything uses DNS! Don't forget SIP, don't forget debug=20 > tools people use with IP and IPv6 addresses only and no names. > yes i agree imho, what you described above is an optimization for a very common case but you need to cope with the general case when packets passing by the=20= ITR are not preceeded by a DNS query which AFICT can happne in at least=20= 4 situations: - when the host is not using the DNS and it uses directly ip addresses - when the cache of the ITR was cleaned but the host still caches the=20 id asocicated to a fqdn - referrals and callbacks - when the communication is rerouted because of a failure thorugh an=20 alternative router that is different to the one that made the initial=20 resolution regards, marcelo > So I wouldn't want to have a mechanism for every type of application=20= > directory service we have. Other examples of directory services is=20 > AIM, Skype, and BitTorrent, which are very application specific. > > Dino > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 06:17:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwKf-0003Za-Q0; Thu, 12 Apr 2007 06:15:13 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HbwKe-0003Y4-9O for ram@iab.org; Thu, 12 Apr 2007 06:15:12 -0400 Received: from smtp03.uc3m.es ([163.117.136.123]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HbwKd-0006Nd-Qf for ram@iab.org; Thu, 12 Apr 2007 06:15:12 -0400 Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 18C57BFAD8; Thu, 12 Apr 2007 12:15:11 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp03.uc3m.es (Postfix) with ESMTP id 005B9BE359; Thu, 12 Apr 2007 12:15:10 +0200 (CEST) In-Reply-To: <6FD29B3B-2949-4030-B7C0-2B1097D54F36@cisco.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> <6FD 29B3B-2949-4030-B7C0-2B1097D54F36@cisco.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <636f024e0055a3cf00d578b8ee299a98@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Thu, 12 Apr 2007 12:15:10 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Cc: "Templin, Fred L" , 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 El 12/04/2007, a las 0:18, Dino Farinacci escribi=F3: >> In particular, you need to be capable of restoring the ID to locator=20= >> mapping information in the backup box, which implies or either that=20= >> you distribute the id loc mapping information about all ongoing=20 >> communications from the primary box to all backup boxes when the=20 >> communication starts or that you have a mechanism to restore such=20 >> information when the primary is down. Such mechanism for restoring=20 >> the information should provide the means to retrieve the locators=20 >> associated to the destiantion identifier > > The way we spec'ed this in the LISP draft is to have both ETRs=20 > configure the IP addresses of all loopback addresses among them. So a=20= > packet that enters one of them can respond with an ICMP reply for all=20= > locators. On packet egress from the site, the chosen exit ITR would do=20= > the mapping independently of the other. So there is no need for=20 > synchronization. > i don't understand this... i have sent this question a while ago that described this exact=20 situation, maybe you can describe how LISP deals with this=20 situation.... I assume we are using LISP1 Consider that we have a host A in a site a that has EID EIDA (which is=20= globally routable in order to be able to bootstrap the initial=20 EID-to-RLOC mapping) and RLOCA which is a different address. Suppose=20 that site We have another host B located in a different site b that has a another=20= locator RLOCB. Suppose that both site a and site b has multiple ISPs=20 (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=20 packet back to the ITRB1 with the RLOCA information and the mapping=20 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=20= locators for host A, it will start sending tunneled packets using RLOCA=20= as dest address in the outer header and the communication is preserved=20= 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=20= used for site B, so packets are rerouted to that backup ITRB1 for site=20= b. But the problem is that packets that host b is sending contain EIDA as=20= destiantion address which is unfortunatelly unreachable at this time.=20 this was not a problem before because ITRB1 had the alternative locator=20= information, but it has failed. The backup router ITRB1 does not=20 contain the alternative locator information for EIDa (i.e. RLOCA), so=20 how can the communication survive this outage? I mean, i guess that fault tolerance is the key feature and the LISP=20 boxes cannot become a single point of failure, so i guess it should be=20= possible to survive this type of situations regards, marcelo > Dino > > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 12 12:21: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 1Hc21K-00032X-HK; Thu, 12 Apr 2007 12:19:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hc21I-00032K-4m for ram@iab.org; Thu, 12 Apr 2007 12:19:37 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hc21F-0007kM-RT for ram@iab.org; Thu, 12 Apr 2007 12:19:36 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3CGJV46026367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 12 Apr 2007 09:19:32 -0700 (PDT) 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 l3CGJVvv017319; Thu, 12 Apr 2007 09:19:31 -0700 (PDT) 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 l3CGJM5L016771; Thu, 12 Apr 2007 09:19:31 -0700 (PDT) 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); Thu, 12 Apr 2007 09:19:29 -0700 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: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Thu, 12 Apr 2007 09:19:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6DF@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Thread-Index: Acd85M3cBPiiAA2+ST69LIongZalhAAONQyw References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> <39! C363776A4 E8C4A94691D2 BD9D1C9A1029ED6D4@XCH-NW-7V2.nw.nos.boeing.com> From: "Templin, Fred L" To: "marcelo bagnulo braun" X-OriginalArrivalTime: 12 Apr 2007 16:19:29.0219 (UTC) FILETIME=[5897E930:01C77D1E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Marcelo, > > If there is no way to ensure that the host will always stick > > with the same ITR (which I'm not yet convinced of), then it > > would have to be something like a site-local resolution > > service keyed off the destination IP address, right? >=20 > this in one option, since you need to restore state that was already=20 > available in the site, so you can have it replicated at the=20 > momento of=20 > the creation of the state. the other option is to allow to=20 > restore the=20 > information retrieving the information from outside the site (from=20 > where it came initially) What about the possibility of having the host stick with the same ITR it chose to do the mapping on a per-session basis? That way, if the ITR fails then the sessions in progress via that ITR fail, but new sessions can choose alternate ITRs. If that seems too onerous, then we have the requirement to restore state via either site-local information or global information. But, in the case of DNS, would restoring state via global information require a fully-populated in6.arpa? Seems like a dead end in terms of scalability, doesn't it? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 00:29:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcDOG-0001FZ-Mq; Fri, 13 Apr 2007 00:28:04 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcDOF-0001FN-Jl for ram@iab.org; Fri, 13 Apr 2007 00:28:03 -0400 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 1HcDOF-0007F5-1g for ram@iab.org; Fri, 13 Apr 2007 00:28:03 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 12 Apr 2007 21:28:04 -0700 X-IronPort-AV: i="4.14,405,1170662400"; d="scan'208"; a="477959782:sNHT58954176" 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 l3D4S2Fh014792; Thu, 12 Apr 2007 21:28:02 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3D4RcZf024400; Fri, 13 Apr 2007 04:27:58 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 21:27:53 -0700 Received: from [192.168.0.4] ([10.21.144.169]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 Apr 2007 21:27:53 -0700 In-Reply-To: <25ecebd4d02476187199445d63130075@it.uc3m.es> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> 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: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Thu, 12 Apr 2007 21:27:51 -0700 To: marcelo bagnulo braun X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 04:27:53.0260 (UTC) FILETIME=[1A3B56C0:01C77D84] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6123; t=1176438482; x=1177302482; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=C5wgq3YAemEbQawOLhG9HtMQUeNTY2XBTDKbQzDiOWg=; b=AVlImNOl6G4ZByLm/IFd3i3GhQJkaSvdiXDvvcisB55dgXYSKwKj+85Qfl5jyM5o/In+4itK HkG0J/YBWxZraEafmZ04cv4fr5pSybkhelkWRhWUmPTAWYlUzjLbwf9r; 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: 827a2a57ca7ab0837847220f447e8d56 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 >>> so are you envisioning an hybrid system that has both the push >>> and pull models? In such scheme there would be these mesh of high >>> level routers that exchange the whole loc id mapping database and >>> then smaller routers that use the pull model to query these high >>> level routers? >> >> Yes, I think something like that. >> >>> the new protocol would then run between these high level routers, >>> is that it? >> >> Yes, which will be trusted. As well as having a registration >> procedure that is pub/priv key protected for the ETRs to register >> EID-to-RLOC mappings. >> > > So are you using a trust model that is based on a closed set of > participants that trust each other rather than a mean to certify > that the actual information about binding is correct? Yes. >> I think we have a good demarcation design where the LISP-00 ID can >> use various means to obtain the mappings. I can see any or all of >> the following: >> >> o Static > > i don't think we should preclude this one, but i don't think it is > general enough to solve our problems (i would leave it as a corner > case for testing and exceptions) May be adequate in TE-ITRs. >> o ICMP > > My take on this one is that much needs to change from its current > form to be secured. In particular you will need a few more message > exchange to achieve this. I realize that. That we can fix. Not worried about it too much. > Besides, you need a valid ID to locator mapping (with at least one > working locator) to actually send the initial request, so this > needs to be complemented with an additional mechanism. In LISP 1, > the mechanism is the identity, since the identifier is also a valid > locator. I don't understand your point here. >> o DNS > > not sure what do you mean here... > > the DNS as used in HIP? i.e. using the DNS to obtain both the > identifier and the locator set associated to a fqdn > or the DNS system to retrieve identifier to locator mapping, like > for instance using ULAs as identifiers and using the DNS reverse > tree entry for the ULA for retrieving the locators associated with > this identifier? The way we have been talking about it. Using DNS store mappings. > the DNS as a generic protocol independent of the current DNS system > to make a directory service for retrieving Id to locator mapping? Right. > In any case, in order to answer this question, i guess that an > important previous question is how do you think the identifier > namespace will be? I mean, it seems that DNS type of approach will > not scale to support an 128 bit unstrucutred identifier namespace. > OTOH, if you are thinking of using ULAs or PI addresses as > identifier, then this may work What will? 128-bits is a lot of addresses. Shouldn't even try. >> o Push-only >> o Push-n-pull > > i like your argument that it is good not to require every ITR to > have the full database, even in a push model. I think we should > continue exploring this solution space Okay, sounds good. >> o Pull with new database >> > > again, i think this is closely related with the characteristics of > the identifier namespace. If we have an existnet protocol like the > DNS that can provide this feature, i don't see the need for this. How you pull and what you pull don't have to be related. I personally like prefixes where the size of the prefix is based on the number of systems you need assign IDs to. > maybe the push and pull approach could be based on BGP+DNS... Could. >>>>> note that for globally distributing the ID to locator mapping >>>>> information, you would just need to enable another instance of >>>>> BGP with maybe some extensions, that would >>>> >>>> That was a possibility we considered with LISP 1.5. >>> >>> i don't think this is similar than LISP 1.5, please see below... >> >> I know, because we wouldn't be routing EIDs. But if we didn't want >> to drop packets in the ITR, the ITR could encapsulate to one of >> the high-level routers that would have the mapping and then it >> would "re-encapsulate" (versus recursive encapsulate as the LISP >> ID states) to the site's ETR. >> > > something similar like a default route for EIDs? Yes, I think it is very likely that many ITRs (for ease of management) will have a single EID entry that looks like this: 0.0.0.0/0 -> {locator1, locator2} > you may end up with a similar concept of the DFZ but for routers > that know how to map identifiers... Right. >> This increases stretch that we *could* stick with, or the ETR >> could send the mapping to the ITR via an ICMP EID-to-RLOC Reply. >> > > yes, i think this additional stretch could be acceptable for a few > initial packets It's the price to pay for scaling. >> Yes, understand. Lixia made the same suggestion using the DNS >> protocol. That is use DNS the protocol as your query/reply >> protocol but don't run it on UDP 53. >> >> But I have to beg the question, why people think this is the long >> pole in the tent? That is designing a straight-forward protocol >> shouldn't be hard or time consuming. > > imho, established well known protocols that have already been > tested and are stable are better choice than new protocols, that > need to mature. Of course, this only if we don't overload existent > usages. For that reason, i think that if we can reuse the protocol > but maybe not the actual current system, seems the best tradeoff > (of course if the protocols do provide the required functionality, > which is not at all clear yet) I've seen it good and bad both ways. But I have found you take the good from the past and leave the bad in the past. ;-) > i mean having a draft describing the needs in term of policy and TE > from mutlihomed end sites and isps would be a great help in order > to design a solution that suit their needs... Good idea. Let's see if I can draft some people. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 06:23:28 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIv9-0003Cg-Tp; Fri, 13 Apr 2007 06:22:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcIv8-0003CZ-8d for ram@iab.org; Fri, 13 Apr 2007 06:22:22 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcIv6-0000Q0-Qg for ram@iab.org; Fri, 13 Apr 2007 06:22:22 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id 45D2359E40; Fri, 13 Apr 2007 20:22:13 +1000 (EST) Message-ID: <461F59CA.20709@firstpr.com.au> Date: Fri, 13 Apr 2007 20:22:02 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [RAM] Paper on FIB structures 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 list member told me of a "Stanford paper which covers some very elegant FIB structures, and describes some of the others that are considered. These papers talk about the trade-offs in number of look ups, amount of memory, etc..." He couldn't point me to it and I couldn't find mention of it looking in the archives. Does anyone recall such a paper? - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 07:15:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJk1-0008GA-RA; Fri, 13 Apr 2007 07:14:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcJjz-0008Fj-VS for ram@iab.org; Fri, 13 Apr 2007 07:14:55 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcJjy-0001qM-GN for ram@iab.org; Fri, 13 Apr 2007 07:14:55 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 4BF4217A828; Fri, 13 Apr 2007 13:14:53 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id EF78217A80E; Fri, 13 Apr 2007 13:14:52 +0200 (CEST) In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6DF@XCH-NW-7V2.nw.nos.boeing.com> References: <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com><460D253A.100@cisco.com><460FE3D6.3040300@cisco.com><03F894F9-33C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB.7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.org><46112D10.8010201@cisco.com><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH-NW-7V2.nw.nos.boeing.com> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C2@XCH-NW-7V2.nw.nos.boeing.com> <461C8C4A.8050102@zurich.ibm.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6D1@XCH-NW-7V2.nw.nos.boeing.com> <39! C363776A4 E8C4A94691D2 BD9D1C9A1029ED6D4@XCH-NW-7V2.nw.nos.boeing.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6DF@XCH-NW-7V2.nw.nos.boeing.com> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Fri, 13 Apr 2007 13:14:53 +0200 To: "Templin, Fred L" X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 El 12/04/2007, a las 18:19, Templin, Fred L escribi=F3: > Marcelo, > >>> If there is no way to ensure that the host will always stick >>> with the same ITR (which I'm not yet convinced of), then it >>> would have to be something like a site-local resolution >>> service keyed off the destination IP address, right? >> >> this in one option, since you need to restore state that was already >> available in the site, so you can have it replicated at the >> momento of >> the creation of the state. the other option is to allow to >> restore the >> information retrieving the information from outside the site (from >> where it came initially) > > What about the possibility of having the host stick with > the same ITR it chose to do the mapping on a per-session > basis? That way, if the ITR fails then the sessions in > progress via that ITR fail, but new sessions can choose > alternate ITRs. > this would be much easier problem to solve and would deal with many=20 common situations. But for the last few years, the focus of the work on=20= multihoming seemd to be preserving established communications through=20 outages (since this is provided by current bgp based multihoming=20 solution) so, i am assuming that this is still a required capability. If this is=20= not the case, then we have a much wider range of approaches that are=20 acceptable > If that seems too onerous, then we have the requirement to > restore state via either site-local information or global > information. But, in the case of DNS, would restoring state > via global information require a fully-populated in6.arpa? well, fully populated for those who have eid that differ from locators=20= (or with multiple locators) > Seems like a dead end in terms of scalability, doesn't it? why do you say this? from the figures that D. Conrad send to ml about the current number of=20= entries in the DNS, the system seems to scale pretty well and doesn't=20 seem to be having big problems to deal with the current size... but maybe some DNS experts could comment on this one... Regards, marcelo > > Fred > fred.l.templin@boeing.com > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 08:51:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLEk-0002g8-MX; Fri, 13 Apr 2007 08:50:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcLEk-0002g3-E5 for ram@iab.org; Fri, 13 Apr 2007 08:50:46 -0400 Received: from e5.ny.us.ibm.com ([32.97.182.145]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcLEj-0003mA-6X for ram@iab.org; Fri, 13 Apr 2007 08:50:46 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id l3DCoiXb007344 for ; Fri, 13 Apr 2007 08:50:44 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3DCoiBR305980 for ; Fri, 13 Apr 2007 08:50:44 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3DCoiBH028615 for ; Fri, 13 Apr 2007 08:50:44 -0400 Received: from cichlid.raleigh.ibm.com (wecm-9-67-156-134.wecm.ibm.com [9.67.156.134]) by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3DCogJF028560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 13 Apr 2007 08:50:43 -0400 Received: from cichlid.raleigh.ibm.com (localhost.localdomain [127.0.0.1]) by cichlid.raleigh.ibm.com (8.13.8/8.12.5) with ESMTP id l3DComsY007765 for ; Fri, 13 Apr 2007 08:50:49 -0400 Message-Id: <200704131250.l3DComsY007765@cichlid.raleigh.ibm.com> To: ram@iab.org Date: Fri, 13 Apr 2007 08:50:47 -0400 From: Thomas Narten X-Spam-Score: 1.4 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [RAM] Weekly posting summary for 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 Total of 65 messages in the last 7 days. script run at: Fri Apr 13 00:53:03 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 26.15% | 17 | 28.07% | 126004 | marcelo@it.uc3m.es 15.38% | 10 | 15.93% | 71501 | fred.l.templin@boeing.com 10.77% | 7 | 11.99% | 53835 | dino@cisco.com 9.23% | 6 | 11.44% | 51374 | rw@firstpr.com.au 9.23% | 6 | 9.42% | 42292 | tli@cisco.com 6.15% | 4 | 4.89% | 21932 | brc@zurich.ibm.com 4.62% | 3 | 3.83% | 17173 | pds@lugs.com 4.62% | 3 | 3.60% | 16155 | rdobbins@cisco.com 3.08% | 2 | 1.74% | 7820 | jnc@mercury.lcs.mit.edu 1.54% | 1 | 1.61% | 7248 | tseely@sprint.net 1.54% | 1 | 1.55% | 6937 | narten@us.ibm.com 1.54% | 1 | 1.45% | 6506 | riw@cisco.com 1.54% | 1 | 1.34% | 6029 | dmm@1-4-5.net 1.54% | 1 | 1.30% | 5839 | christopher.morrow@verizonbusiness.com 1.54% | 1 | 1.00% | 4473 | jefsey@jefsey.com 1.54% | 1 | 0.85% | 3804 | rja@extremenetworks.com --------+------+--------+----------+------------------------ 100.00% | 65 |100.00% | 448922 | Total _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 13:29:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPZq-00025o-DZ; Fri, 13 Apr 2007 13:28:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPZo-00020g-8v for ram@iab.org; Fri, 13 Apr 2007 13:28:48 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPZl-0004zw-R1 for ram@iab.org; Fri, 13 Apr 2007 13:28:48 -0400 Received: from sj-dkim-6.cisco.com ([171.68.10.81]) by sj-iport-4.cisco.com with ESMTP; 13 Apr 2007 10:28:45 -0700 X-IronPort-AV: i="4.14,408,1170662400"; d="scan'208"; a="53490575:sNHT53043984" 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 l3DHSj3U031665 for ; Fri, 13 Apr 2007 10:28:45 -0700 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 l3DHSex9003121 for ; Fri, 13 Apr 2007 17:28:45 GMT 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); Fri, 13 Apr 2007 10:28:42 -0700 Received: from [192.168.0.4] ([10.21.155.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:28:41 -0700 Mime-Version: 1.0 (Apple Message framework v752.3) References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Date: Fri, 13 Apr 2007 10:28:41 -0700 To: ram@iab.org X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 17:28:41.0892 (UTC) FILETIME=[2E314640:01C77DF1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3315; t=1176485325; x=1177349325; 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:=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=20requires=20appr oval |Sender:=20; bh=ny32BgDyYfBdk0S4oPMKkilmU6c7UFMURWJfIXcfktI=; b=gk5Hhg1E4IqpwRQJ65l9O9eC3m2iHBRQXfYMvvpkHXtDQJquwpgTSHnFF/D5LxwplJsXlgPf Vv/b0O3RNDAPvUeOvHD9AtaubO7mOLNvu0QsKu5yzDX7EV1QukQjBtMV; 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: 10d3e4e3c32e363f129e380e644649be Subject: [RAM] Fwd: RAM post from dino@cisco.com requires approval 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 Resend. Dino Begin forwarded message: > From: Lixia Zhang > Date: April 13, 2007 8:06:27 AM PDT > To: Dino Farinacci > Subject: Fwd: RAM post from dino@cisco.com requires approval > > this is the msg that was held up. > where came that long reference list? > > > Begin forwarded message: > >> >> From: dino@cisco.com >> Date: April 11, 2007 10:54:53 PM PDT >> >> >> References: >> <20070329192859.4630E87323@mercury.lcs.mit.edu><98D229CF-EC80-4274- >> AF15-0F3467BC8E05@cisco.com><460D253A. >> 100@cisco.com>> AA94342419E5@virtualized.org><460FE3D6.3040300@cisco.com><03F894F9-33 >> C8-4315-8B58-F6C7ABCEA3FB@virtualized.org><461124DB. >> 7010106@cisco.com><42377AD3-7843-44E1-9160-932CBD948C08@virtualized.o >> rg><46112D10.8010201@cisco.com>> virtualized.org><6FF46E54-C0B2-49E0-AC4D-E51F625C7610@cisco.com> >> >> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6AF@XCH- >> NW-7V2.nw.nos.boeing.com> >> >> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6C0@XCH- >> NW-7V2.nw.nos.boeing.com> >> <41e1d3a21080bb4e62090da55d8df224@it.uc3m.es> <5E51FC14-95F1-4A4F- >> BC5F-947E0BD4594C@cisco.com> >> <20070410215957.qoqwxcjwcv2ocssc@webcartero01.uc3m.es> > AB2A-4A56-8956-C2A35EACF6D7@cisco.com> >> <2bd56ee22c0fd68f9d8589b9551b3c2e@it.uc3m.es> >> > 7CD92A3F0@cisco.com> <558071D3-41B4-4362- >> A984-44361175427B@lugs.com> >> Mime-Version: 1.0 (Apple Message framework v752.3) >> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed >> Message-Id: >> Cc: marcelo bagnulo braun , >> Tony Li , >> "Templin, Fred L" , >> ram@iab.org >> Content-Transfer-Encoding: 7bit >> From: Dino Farinacci >> Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP >> Date: Wed, 11 Apr 2007 22:54:51 -0700 >> To: Peter Schoenmaker >> X-Mailer: Apple Mail (2.752.3) >> Return-Path: dino@cisco.com >> X-OriginalArrivalTime: 12 Apr 2007 05:54:52.0895 (UTC) FILETIME= >> [16F6AEF0:01C77CC7] >> >>> I hope ultimately customers use PI addresses that are not injected >>> into the BGP core. This seems like the ultimate solution, to give >>> every host a unique identifier. link-local/private addresses are >>> only an interim step. >> >> So let me ask you this Peter. If you get longer prefix routes (but >> not more of them) does that give you (a tier-1 ISP) better >> opportunity to aggregate to your peers? >> >> Dino >> >> >> >> >> From: ram-request@iab.org >> Subject: confirm 2b3f21d937eef3857989c83e845322e5041b4736 >> >> >> If you reply to this message, keeping the Subject: header intact, >> Mailman will discard the held message. Do this if the message is >> spam. If you reply to this message and include an Approved: header >> with the list password in it, the message will be approved for >> posting >> to the list. The Approved: header can also appear in the first line >> of the body of the reply. >> _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 13:36:31 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPgQ-00086M-QS; Fri, 13 Apr 2007 13:35:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPgQ-00086B-4Q for ram@iab.org; Fri, 13 Apr 2007 13:35:38 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPgM-00013e-SY for ram@iab.org; Fri, 13 Apr 2007 13:35:38 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 13 Apr 2007 10:35:34 -0700 X-IronPort-AV: i="4.14,408,1170662400"; d="scan'208"; a="707759234:sNHT29855860" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3DHZYJ30583; Fri, 13 Apr 2007 10:35:34 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704131735.l3DHZYJ30583@merlot.juniper.net> To: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: Your message of "Mon, 02 Apr 2007 21:45:20 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62480.1176485734.1@juniper.net> Date: Fri, 13 Apr 2007 10:35:34 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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, > > This would be an good example to illustrate that LISP 1.5 offer > > *no* reduction of the volume of routing information. To the contrary, > > this example would illustrate how LISP 1.5 would result in increasing > > volume of routing information. > > It reduces the unicast FIB. Any *empirical* evidences to support the above claim would be greatly appreciated. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 13:39:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPjD-0001GY-01; Fri, 13 Apr 2007 13:38:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPjB-0001GT-1k for ram@iab.org; Fri, 13 Apr 2007 13:38:29 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPj9-0002D3-Q9 for ram@iab.org; Fri, 13 Apr 2007 13:38:29 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 13 Apr 2007 10:38:28 -0700 X-IronPort-AV: i="4.14,408,1170662400"; d="scan'208"; a="707760828:sNHT31793728" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3DHcRJ33869; Fri, 13 Apr 2007 10:38:27 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704131738.l3DHcRJ33869@merlot.juniper.net> To: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: Your message of "Mon, 02 Apr 2007 21:45:20 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <62855.1176485907.1@juniper.net> Date: Fri, 13 Apr 2007 10:38:27 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 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, > > This would be an good example to illustrate that LISP 1.5 offer > > *no* reduction of the volume of routing information. To the contrary, > > this example would illustrate how LISP 1.5 would result in increasing > > volume of routing information. > > It reduces the unicast FIB. Does that mean that the size of RIB is not a problem ? Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 13:45:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPp0-0005BP-F0; Fri, 13 Apr 2007 13:44:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPoz-0005BK-So for ram@iab.org; Fri, 13 Apr 2007 13:44:29 -0400 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 1HcPoy-0003pi-J7 for ram@iab.org; Fri, 13 Apr 2007 13:44:29 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2007 10:44:24 -0700 X-IronPort-AV: i="4.14,408,1170662400"; d="scan'208"; a="369765944:sNHT118698646" 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 l3DHiN7b015882; Fri, 13 Apr 2007 10:44:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l3DHiAF2020676; Fri, 13 Apr 2007 17:44:23 GMT 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); Fri, 13 Apr 2007 10:44:23 -0700 Received: from [192.168.0.4] ([10.21.155.151]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 10:44:23 -0700 In-Reply-To: <200704131735.l3DHZYJ30583@merlot.juniper.net> References: <200704131735.l3DHZYJ30583@merlot.juniper.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] Incremental Deployment of LISP Date: Fri, 13 Apr 2007 10:44:22 -0700 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 17:44:23.0189 (UTC) FILETIME=[5F3FCC50:01C77DF3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1202; t=1176486263; x=1177350263; 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]=20Incremental=20Deployment=20of=20LISP=20 |Sender:=20; bh=HLaj8Dmxd0O7x5/5HhhN+y29XNQIc/WDO8aVcZGjyrw=; b=zdLVdlaO1G/pJKmStQzl5ySL00xYKAhJDMrmMOaJFmezk+10PptVzWtaiJmTmRB4mwdmV7P0 Kt2VwZGHBCNmCpjP84vd/Ls2dXhXIOoJijOMVMCG5gK/30UO/c+Xg2AZ; 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: 52e1467c2184c31006318542db5614d5 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 would be an good example to illustrate that LISP 1.5 offer >>> *no* reduction of the volume of routing information. To the >>> contrary, >>> this example would illustrate how LISP 1.5 would result in >>> increasing >>> volume of routing information. >> >> It reduces the unicast FIB. > > Any *empirical* evidences to support the above claim would be greatly > appreciated. The point is that the PI prefixes which are in the core today can be removed because they will be routed on another, smaller topology, to be used to probe for locator replies. So there is evidence that if you use the "no network " command in BGP, the neighbor router does not store in it's RIB or FIB. Therefore there is a reduction. >>> This would be an good example to illustrate that LISP 1.5 offer >>> *no* reduction of the volume of routing information. To the >>> contrary, >>> this example would illustrate how LISP 1.5 would result in >>> increasing >>> volume of routing information. >>> >> >> It reduces the unicast FIB. >> > > Does that mean that the size of RIB is not a problem ? Less is always better from many perspectives. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 13:50: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 1HcPtf-0006u9-6j; Fri, 13 Apr 2007 13:49:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcPte-0006sb-AR for ram@iab.org; Fri, 13 Apr 2007 13:49:18 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcPtc-0005ka-R7 for ram@iab.org; Fri, 13 Apr 2007 13:49:18 -0400 Received: from [192.168.200.103] ([199.237.6.52]) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l3DHn98j035878 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2007 13:49:09 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> Content-Transfer-Encoding: 7bit From: Peter Schoenmaker Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 13:48:55 -0400 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Fri, 13 Apr 2007 13:49:09 -0400 (EDT) X-Spam-Score: 1.4 (+) X-Scan-Signature: 93238566e09e6e262849b4f805833007 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 Apr 13, 2007, at 1:28 PM, Dino Farinacci wrote: >>> >>>> I hope ultimately customers use PI addresses that are not injected >>>> into the BGP core. This seems like the ultimate solution, to give >>>> every host a unique identifier. link-local/private addresses are >>>> only an interim step. >>> >>> So let me ask you this Peter. If you get longer prefix routes (but >>> not more of them) does that give you (a tier-1 ISP) better >>> opportunity to aggregate to your peers? Today it does not make a difference because we do not aggregate routes from customers that we recieve via BGP. The main reason we do this is that we do not know if they are announcing the same route to other providers. peter _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:01:24 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSsV-0006p4-EX; Fri, 13 Apr 2007 17:00:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcSsU-0006ox-SE for ram@iab.org; Fri, 13 Apr 2007 17:00:18 -0400 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 1HcSsS-0001vb-Na for ram@iab.org; Fri, 13 Apr 2007 17:00:18 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 13 Apr 2007 14:00:15 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="478172921:sNHT45816042" 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 l3DL0EWG016818; Fri, 13 Apr 2007 14:00:14 -0700 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 l3DL08Mb029579; Fri, 13 Apr 2007 21:00:13 GMT 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, 13 Apr 2007 14:00:09 -0700 Received: from [171.71.55.122] ([171.71.55.122]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:00:09 -0700 In-Reply-To: <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 14:00:08 -0700 To: Peter Schoenmaker X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 21:00:09.0190 (UTC) FILETIME=[B8695060:01C77E0E] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=711; t=1176498014; x=1177362014; 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]=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=2 0requires=20approval |Sender:=20; bh=VonIbI5cM2qxsRXBUhGyfDiAFUCkdO/tSjqCl0p0ghs=; b=eEMDRmDCpEEClTgdq3yDmL5u3AgoHlD9cLf3HetsTlU5tpBjECLNy2Kmetjf4Kb0Rv98wSmw MvAp/cAVw4shQLs4GPdG6OhX2faxMJaCAbOWHk2HISeQHXqTrfjRrGur; 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: 08170828343bcf1325e4a0fb4584481c 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 >>>> So let me ask you this Peter. If you get longer prefix routes (but >>>> not more of them) does that give you (a tier-1 ISP) better >>>> opportunity to aggregate to your peers? > > Today it does not make a difference because we do not aggregate > routes from customers that we recieve via BGP. The main reason we > do this is that we do not know if they are announcing the same > route to other providers. Don't you think this process can change if we had a locator-id split? That is the site would only advertise the blocks you gave them back to you and no where else. Even if they didn't follow this process, you could still aggregate. Would this help on the core side? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:17:46 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT8U-00058L-DU; Fri, 13 Apr 2007 17:16:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcT8S-00058F-U1 for ram@iab.org; Fri, 13 Apr 2007 17:16:48 -0400 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 1HcT8R-000425-Kc for ram@iab.org; Fri, 13 Apr 2007 17:16:48 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 13 Apr 2007 14:16:48 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="369800546:sNHT46977500" 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 l3DLGlro030645; Fri, 13 Apr 2007 14:16:47 -0700 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 l3DLGVZX028171; Fri, 13 Apr 2007 21:16:46 GMT 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, 13 Apr 2007 14:16:33 -0700 Received: from [192.168.0.100] ([10.21.155.102]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:16:33 -0700 In-Reply-To: <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <7EAB0330-3845-44D8-BC86-228233DF264F@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 14:16:28 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 21:16:33.0628 (UTC) FILETIME=[032EA1C0:01C77E11] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=702; t=1176499007; x=1177363007; 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]=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=2 0requires=20approval |Sender:=20; bh=xY8+v5WbIrTX9IBRP3jSl6l12d4LOd2kiwU6sRq9Oa0=; b=iQVWZ+XrJNNLO+5MCsx3Ie1UQB781pcSftCg6iio2z9e55rJuI1d3dW3QaIT3VYuTKO+SKSN OPl/0c2OxEsnNjDoG0Io1HxSD4vdAq+8O6KPIChIog1sJWkMFX1y+TXT; Authentication-Results: sj-dkim-4; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 1.4 (+) 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 >> Today it does not make a difference because we do not aggregate >> routes from customers that we recieve via BGP. The main reason we >> do this is that we do not know if they are announcing the same >> route to other providers. > > Don't you think this process can change if we had a locator-id > split? That is the site would only advertise the blocks you gave > them back to you and no where else. Even if they didn't follow this > process, you could still aggregate. Would this help on the core side? If we do the split properly, then the end-site wouldn't need to advertise anything to the ISP in the first place, so there'd be nothing to aggregate. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:22:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTCv-0001DH-Gc; Fri, 13 Apr 2007 17:21:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTCu-00013e-5Z for ram@iab.org; Fri, 13 Apr 2007 17:21:24 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTCs-0007gv-O7 for ram@iab.org; Fri, 13 Apr 2007 17:21:24 -0400 Received: from [192.168.200.103] ([199.237.6.52]) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l3DLLJls036920 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2007 17:21:19 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.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: Peter Schoenmaker Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 17:21:13 -0400 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Fri, 13 Apr 2007 17:21:19 -0400 (EDT) X-Spam-Score: 1.4 (+) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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 Apr 13, 2007, at 5:00 PM, Dino Farinacci wrote: >>>>> So let me ask you this Peter. If you get longer prefix routes (but >>>>> not more of them) does that give you (a tier-1 ISP) better >>>>> opportunity to aggregate to your peers? >> >> Today it does not make a difference because we do not aggregate >> routes from customers that we recieve via BGP. The main reason we >> do this is that we do not know if they are announcing the same >> route to other providers. > > Don't you think this process can change if we had a locator-id > split? That is the site would only advertise the blocks you gave > them back to you and no where else. Even if they didn't follow this > process, you could still aggregate. Would this help on the core side? The BGP policy may not change, so we may still not want to aggregate bgp announcement. The key difference will be that customer will not need BGP in order to multihome. Teaching customers that they do not need BGP to multihome may become a difficult education process. peter > > Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:29:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTKG-0007r5-4O; Fri, 13 Apr 2007 17:29:00 -0400 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTKD-0007r0-VQ for ram@iab.org; Fri, 13 Apr 2007 17:28:58 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1HcTKC-0006qn-Hv for ram@iab.org; Fri, 13 Apr 2007 17:28:57 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2007 14:28:54 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="135732913:sNHT48845187" 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 l3DLSsvc020453; Fri, 13 Apr 2007 14:28:54 -0700 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 l3DLSsZX006846; Fri, 13 Apr 2007 21:28:54 GMT 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); Fri, 13 Apr 2007 14:28:45 -0700 Received: from [171.71.55.122] ([171.71.55.122]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:28:44 -0700 In-Reply-To: <7EAB0330-3845-44D8-BC86-228233DF264F@cisco.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> <7EAB0330-3845-44D8-BC86-228233DF264F@cisco.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] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 14:28:43 -0700 To: Tony Li X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 21:28:44.0392 (UTC) FILETIME=[B6C05E80:01C77E12] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=222; t=1176499734; x=1177363734; 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]=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=2 0requires=20approval |Sender:=20; bh=/4l7E7epTbNGMPUtAXieOS7sugbJobR6UCOta/jwODk=; b=jOdKP1P++CtaXHItZ7443X13Rf0wuK342I5vGoyvbO0RWPY+S4CsisGbjSgYBN5pe7WP9dqv 9FyDqEibiF57hL0dDKscNdjWA0nsPh0RDb4a75U+vFcvlH1NMadrKuIj; 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: 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 > If we do the split properly, then the end-site wouldn't need to > advertise anything to the ISP in the first place, so there'd be > nothing to aggregate. I was referring to the ISP further aggregating. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTLw-0000xP-8v; Fri, 13 Apr 2007 17:30:44 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTLv-0000xH-4j for ram@iab.org; Fri, 13 Apr 2007 17:30:43 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTLt-0004xp-RI for ram@iab.org; Fri, 13 Apr 2007 17:30:43 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2007 14:30:41 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="135733637:sNHT42181686" 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 l3DLUfSB011773; Fri, 13 Apr 2007 14:30:41 -0700 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 l3DLUfEk027893; Fri, 13 Apr 2007 21:30:41 GMT 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); Fri, 13 Apr 2007 14:30:20 -0700 Received: from [171.71.55.122] ([171.71.55.122]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 14:30:19 -0700 In-Reply-To: References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <798E1CE6-A365-44CC-AB89-876C718071E0@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 14:30:18 -0700 To: Peter Schoenmaker X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 21:30:19.0392 (UTC) FILETIME=[EF603800:01C77E12] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=441; t=1176499841; x=1177363841; 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]=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=2 0requires=20approval |Sender:=20; bh=lBtJVBwDmoQTfk223MKPwZMLlcZ5mome+4p9v9fGSYE=; b=P4gyfFeRcJ2KEFDK7qfdF/MNm1JOcZhVq+WUUoHct/Yjdxt3H0d5DGGDuU1FZN8x0SlX4C87 x1bR00KxeN5cWanZNblwrpn/RxZaUeu8wlG4oTxxqcAXnp1+wVYelypk; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > The BGP policy may not change, so we may still not want to > aggregate bgp announcement. The key difference will be that > customer will not need BGP in order to multihome. I see, that sounds like a good OpEx savings to me. > Teaching customers that they do not need BGP to multihome may > become a difficult education process. I'm sure if you tell them they can turn off something, that they will listen. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:36:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTQr-0003H8-T2; Fri, 13 Apr 2007 17:35:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTQr-0003Fv-Ef for ram@iab.org; Fri, 13 Apr 2007 17:35:49 -0400 Received: from murdock.lugs.com ([192.80.15.4]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTQq-0007Hg-2v for ram@iab.org; Fri, 13 Apr 2007 17:35:49 -0400 Received: from [192.168.200.103] ([199.237.6.52]) (authenticated bits=0) by murdock.lugs.com (8.13.6/8.13.6) with ESMTP id l3DLZigH037003 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 13 Apr 2007 17:35:44 -0400 (EDT) (envelope-from pds@lugs.com) In-Reply-To: <798E1CE6-A365-44CC-AB89-876C718071E0@cisco.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> <798E1CE6-A365-44CC-AB89-876C718071E0@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <65ECDC60-C4E3-497D-A005-2D7975E5A511@lugs.com> Content-Transfer-Encoding: 7bit From: Peter Schoenmaker Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 17:35:38 -0400 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-3.0 (murdock.lugs.com [192.80.15.4]); Fri, 13 Apr 2007 17:35:44 -0400 (EDT) X-Spam-Score: 1.4 (+) 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 On Apr 13, 2007, at 5:30 PM, Dino Farinacci wrote: >> The BGP policy may not change, so we may still not want to >> aggregate bgp announcement. The key difference will be that >> customer will not need BGP in order to multihome. > > I see, that sounds like a good OpEx savings to me. > >> Teaching customers that they do not need BGP to multihome may >> become a difficult education process. > > I'm sure if you tell them they can turn off something, that they > will listen. New customers will not be a problem. Customers that are familiar with how BGP multihoming works will be much more difficult to educate to think with a different mindset. peter > > Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 17:38:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTSK-00044u-Fh; Fri, 13 Apr 2007 17:37:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcTSJ-000421-5r for ram@iab.org; Fri, 13 Apr 2007 17:37:19 -0400 Received: from omzesmtp03.mci.com ([199.249.17.11]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcTSG-00087E-RK for ram@iab.org; Fri, 13 Apr 2007 17:37:19 -0400 Received: from pmismtp04.wcomnet.com ([166.37.158.164]) by firewall.mci.com (Iplanet MTA 5.2) with ESMTP id <0JGG00LJGHE4B4@firewall.mci.com> for ram@iab.org; Fri, 13 Apr 2007 21:37:16 +0000 (GMT) Received: from pmismtp04.wcomnet.com ([127.0.0.1]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with SMTP id <0JGG003PMHE4KJ@pmismtp04.mcilink.com> for ram@iab.org; Fri, 13 Apr 2007 21:37:16 +0000 (GMT) Received: from marvin.argfrp.us.uu.net ([153.39.56.19]) by pmismtp04.mcilink.com (iPlanet Messaging Server 5.2 HotFix 2.08 (built Sep 22 2005)) with ESMTP id <0JGG0036SHE3WN@pmismtp04.mcilink.com> for ram@iab.org; Fri, 13 Apr 2007 21:37:16 +0000 (GMT) Date: Fri, 13 Apr 2007 21:37:15 +0000 (GMT) From: "Chris L. Morrow" Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval In-reply-to: X-X-Sender: cmorrow@marvin.argfrp.us.uu.net To: Peter Schoenmaker Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Fri, 13 Apr 2007, Peter Schoenmaker wrote: > > > > Don't you think this process can change if we had a locator-id > > split? That is the site would only advertise the blocks you gave > > them back to you and no where else. Even if they didn't follow this > > process, you could still aggregate. Would this help on the core side? > > The BGP policy may not change, so we may still not want to aggregate > bgp announcement. The key difference will be that customer will not > need BGP in order to multihome. Teaching customers that they do not > need BGP to multihome may become a difficult education process. there is also the issue of what 'size' customer... a smaller site that doesn't have 'PI' space (locator space) may not (will not depending on the split) need bgp at all. A larger site that justifies/needs/pays-for 'PI' (locator) space will still do BGP and participate in the 'DFZ'. This is likely understood, but I think it's good to be explicit that not everything will be behind X large providers. There are shades/degrees and we'll have to deal with that going forward. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 18:58:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUht-00021U-5v; Fri, 13 Apr 2007 18:57:29 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcUhr-000217-AF for ram@iab.org; Fri, 13 Apr 2007 18:57:27 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcUhr-0001C2-0a for ram@iab.org; Fri, 13 Apr 2007 18:57:27 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Apr 2007 15:57:25 -0700 X-IronPort-AV: i="4.14,409,1170662400"; d="scan'208"; a="135759226:sNHT50502717" 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 l3DMvQtA032759; Fri, 13 Apr 2007 15:57:26 -0700 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 l3DMv6Zv024831; Fri, 13 Apr 2007 22:57:26 GMT 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); Fri, 13 Apr 2007 15:57:15 -0700 Received: from [171.71.55.122] ([171.71.55.122]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 13 Apr 2007 15:57:14 -0700 In-Reply-To: References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu> <639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com> <51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com> <348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <332DD4CB-6026-48AC-8176-4D9DD29A6C3D@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Fri, 13 Apr 2007 15:57:14 -0700 To: "Chris L. Morrow" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 13 Apr 2007 22:57:14.0907 (UTC) FILETIME=[1410A6B0:01C77E1F] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1191; t=1176505046; x=1177369046; 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]=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=2 0requires=20approval |Sender:=20; bh=bsqj/Yh8v76dGerRryQ2Gu+VWa5Ggico5tBT1h538mU=; b=0Or4+QAcyN5glkiHsil9oUaxcBQytfCqvT1abN9Vs2nr+LdyqqYZUI97Zj0QcGMSkHpVqhj3 x0d2YBfeLYW3bLAuMFVgtutH11oHsIUCmC7X8Srk5xMznuM26x8Sr+V6; 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: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 >>> >>> Don't you think this process can change if we had a locator-id >>> split? That is the site would only advertise the blocks you gave >>> them back to you and no where else. Even if they didn't follow this >>> process, you could still aggregate. Would this help on the core >>> side? >> >> The BGP policy may not change, so we may still not want to aggregate >> bgp announcement. The key difference will be that customer will not >> need BGP in order to multihome. Teaching customers that they do not >> need BGP to multihome may become a difficult education process. > > there is also the issue of what 'size' customer... a smaller site that > doesn't have 'PI' space (locator space) may not (will not depending > on the > split) need bgp at all. A larger site that justifies/needs/pays- > for 'PI' > (locator) space will still do BGP and participate in the 'DFZ'. Well, you could take a PI advertisement from the site but deploy an ITR on your PE so the PI can stop there. Not sure what your incentive is to do so though. I guess if they pay you big dollars for PI, the cost will be a bit more for you to manage the non-pollution of it. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 13 19:38: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 1HcVKK-0000Od-R8; Fri, 13 Apr 2007 19:37:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcVKJ-0000M4-T1 for ram@iab.org; Fri, 13 Apr 2007 19:37:11 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcVKI-0005Lr-2y for ram@iab.org; Fri, 13 Apr 2007 19:37:11 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9675886AFF; Fri, 13 Apr 2007 19:37:09 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Message-Id: <20070413233709.9675886AFF@mercury.lcs.mit.edu> Date: Fri, 13 Apr 2007 19:37:09 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: Peter Schoenmaker > Teaching customers that they do not need BGP to multihome may become > a difficult education process. This is where the details of how you do routing in a "jack-up" scheme become important. For example, I would use a *syntactically* different address space in the backbone - i.e. *neither* IPv4 *or* IPv6, so that people *can't* insert routes into the new backbone by using BGP (of any flavour). This leaves the legacy IPv4 backbone, wherein their IPv4 address space has to be advertised, if people attached to the legacy backbone are going to be able to reach them. However, if they are N hops away from it, there's not a lot of point to injecting their routes into it, since it will do no good in having any influence in what path their traffic takes once it leaves the IPv4 backbone, i.e. once it gets closer to them and their N multi-homing points. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 14 00:35:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcZxu-0000Mt-LP; Sat, 14 Apr 2007 00:34:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcZxs-0000L0-T5 for ram@iab.org; Sat, 14 Apr 2007 00:34:20 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcZxq-0008QS-Ud for ram@iab.org; Sat, 14 Apr 2007 00:34:20 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id E26CC59DA1; Sat, 14 Apr 2007 14:34:13 +1000 (EST) Message-ID: <462059BB.10309@firstpr.com.au> Date: Sat, 14 Apr 2007 14:34:03 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [RAM] How does LISP recognise which IP addresses to query mapping for? 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 based on IPv4 and my understanding of LISP, which may be faulty. In an IPv4 setting, assuming the current /24 granularity of whether the addresses are advertised in BGP or not, I am curious about how a LISP implementation would handle packets which were addressed to addresses not advertised in BGP. I am thinking mainly of LISP 2 or 3 similar - where the ITR decides to look up the mapping for a particular IP address via DNS or some other mechanism. I don't see how LISP 1 helps reduce the load of growing numbers of prefixes in the BGP routing system. I find it hard to imagine the development of a global alternative routing system for LISP 1.5 and I don't see how LISP 1.5 could be deployed incrementally, since the alternative routing system would need to be in place and LISP routers would need to be in practically every edge network, to ensure continued universal reachability of any addresses which were taken out of the BGP system and accessed as LISP EIDs instead. I think LISP 2 or 3 could have significant benefits, but I think they too would require a complete upgrade, since no-one would want to make their IP addresses inaccessible to the fraction of edge networks which had not installed LISP routers. (Unless there is a way of catching the packets in the DFZ, with special LISP routers - but then someone would need to pay for that, when it should be the responsibility of each edge network to pay for its own LISP capabilities.) I am mainly thinking of a complete upgrade, over 5 or so years, to border routers and transit routers, with SRAM forwarding in border and transit routers and LISP 2/3 functions in the border routers and perhaps in routers within the edge networks. However, the questions below assume only LISP 2 or 3, not SRAM forwarding. I will refer to a "central mapping database", which could be implemented via DNS and/or in some other ways. Here is why I think the central database needs to be able to tell the ITR a definite "No" if the requested IP address is not mapped by the LISP system, and to tell the ITR the prefix which this address is part of, for which the same answer applies. (I assume that a response returning mapping would also indicate the enclosing prefix, as with the 5 bit EID Mask length and 32 bit EID prefix in the draft-farinacci-lisp-00.) I also think there needs to be a TTL or similar - to tell the ITR how long to cache this information for. (I don't see a TTL in the ICMP "Control-Plane Packet Format in draft-farinacci-lisp-00 - but it strikes me that one would be desirable.) If the database simply gave no response to a query about an address which was not mapped as an EID by LISP, then I think there would be problems: Consider the ITR receiving a packet which is addressed to some prefix which it knows is not advertised in the global BGP system. It sends a request to the database. If the only way the database can answer "No" is to not respond, then the ITR has to record that this particular IP address has no LISP mapping, so the packet should be dropped. However, the ITR also needs to remember this for that IP address, for some configurable time, to prevent it repeating the query when another packet arrives for this address. The amount of state to be stored could get out of hand if it was repeated on a large number of IP addresses, as would happen with a user scanning a large number of IP addresses for some reason. If the database always responded by saying "No, this address is not a LISP EID and neither is this prefix, of which it is a member." with a TTL such as an hour or a day, then the ITR can then avoid making similar queries whenever it gets packets addressed to this prefix. It might be helpful if the central database maintained a bit-map file, with one bit for each of the 14.5 million /24 prefixes, where a '1' means that one or more IP addresses in the corresponding /24 was mapped as a LISP EID. The ITRs could download this at boot time. It is 1.8Mbyte and would compress to much smaller than this. The ITRs could periodically request changes, or receive them on a push basis, either directly from the central database or via some special form of BGP update. This would save the ITRs from making queries whenever they encountered a packet addressed to some /24 which was not routable via BGP. Alternatively, if the negative answers had long TTLs and covered large ranges of addresses, after a while, each ITR would accumulate these responses and so cover most of the IP address. However, assuming that in the future there will will be lots (hundreds of thousands) of pockets of IP addresses used for LISP interspersed with ranges used for BGP, then this wouldn't work so well, and downloading and updating a single bit map mask might be more efficient. - Robin http://tools.ietf.org/html/draft-whittle-sram-ip-forwarding-01 http://www.firstpr.com.au/ip/sram-ip-forwarding/ _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 14 11:00:14 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcjiQ-0001Kn-T2; Sat, 14 Apr 2007 10:59:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HcjiP-0001Ki-Qn for ram@iab.org; Sat, 14 Apr 2007 10:59:01 -0400 Received: from kiwi.cs.ucla.edu ([131.179.128.19]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HcjiO-0007DY-Sw for ram@iab.org; Sat, 14 Apr 2007 10:59:01 -0400 Received: from [10.0.1.2] (cpe-76-172-46-192.socal.res.rr.com [76.172.46.192]) by kiwi.cs.ucla.edu (8.13.8+Sun/8.13.8/UCLACS-6.0) with ESMTP id l3EEwwfm005056 for ; Sat, 14 Apr 2007 07:58:59 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v752.2) To: ram@iab.org Message-Id: <399CDBBF-DE36-4547-9CF4-7201FC4C21F3@cs.ucla.edu> From: Lixia Zhang Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Sat, 14 Apr 2007 07:59:02 -0700 X-Mailer: Apple Mail (2.752.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 43ca87c8fcef5d9f6e966e1c3917103e 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="===============2115588015==" Errors-To: ram-bounces@iab.org --===============2115588015== Content-Type: multipart/alternative; boundary=Apple-Mail-5-687047432 --Apple-Mail-5-687047432 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed From: dino@cisco.com Date: April 12, 2007 9:41:23 PM PDT Cc: "Templin, Fred L" , ram@iab.org From: Dino Farinacci Subject: Re: DNS ALG (was Re: [RAM] Incremental Deployment of LISP Date: Thu, 12 Apr 2007 21:41:21 -0700 To: marcelo bagnulo braun > i have sent this question a while ago that described this exact > situation, maybe you can describe how LISP deals with this > situation.... Sure. > 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) Okay, first off the hosts don't have locators. The locators are assigned to the ETRs. > 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 No, not true. ITRB1 prepends an IP header to the host's packet. The outer SA is ITRB1's locator address and the outer DA is the EIDA (copied from the inner DA). This is only used to trigger a mapping reply from the ETR that is responsible for the EID range associated with host A. This happens in both LISP 1.0 and LISP 1.5. > 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. The source address in the ICMP reply is one of ETRA1's locator addresses. The ICMP payload that describes the mapping indicates the *EID-prefix* that ETRA1 is responsible for and a list of all locators for this range (and their priority and weight values for each locator). All locators means IP addresses assigned to it or any other ETR in site A. We have documented this in the spec. > Now bad things start :-) Oh good, the meat. > 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. Ah, no fair, you avoided the real problem. You didn't even try to ask how does ITRB1 know the ETRA1 is not reachable. ;-) We do have answers for them though. ;-) > 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. Yes, of course. There are two ways an ITR determines a locator is not reachable: o It receives an ICMP Unreachable message. o It stops seeing packets it decaps from the EID-prefix range coming from one of the locators in the locator-set. The later is better and more reliable. And I'm not worrying about asymmetric paths. > 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 No, not true. EIDs are always reachable because they are not location addresses. The only time you can't get packets to EIDA, is when all locators are not reachable. > 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? Yes it does. This is not that hard. > 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 If you deploy a single ETR, you have a single point of failure. So you deploy two of them. And if you have two ISP connections, each ETR has two locator addresses, one from each ISP block. Then when the mapping is advertised for this site it is done with a single EID- prefix advertisement with 4 locators. See the section in the spec for locator selection. It is spec'ed to be flexible for the ETR to choose what locators the ITR uses, or the ETR allows the ITR to choose which ones. Dino From: ram-request@iab.org Subject: confirm af86831f93db598d55a443098b7a4569dbaf4b59 If you reply to this message, keeping the Subject: header intact, Mailman will discard the held message. Do this if the message is spam. If you reply to this message and include an Approved: header with the list password in it, the message will be approved for posting to the list. The Approved: header can also appear in the first line of the body of the reply. --Apple-Mail-5-687047432 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1
Date: April 12, 2007 9:41:23 PM = PDT
Cc: "Templin, Fred L" <Fred.L.Templin@boeing.com>= ;,
=A0<= A href=3D"mailto:ram@iab.org">ram@iab.org
From: Dino Farinacci <dino@cisco.com>
Subject: Re: DNS ALG (was Re: [RAM] Incremental = Deployment of LISP
Date: Thu, 12 Apr 2007 = 21:41:21 -0700
To: marcelo bagnulo braun <marcelo@it.uc3m.es>

i have sent this question a = while ago that described this exact =A0
=A0

Sure.

I assume we are using = LISP1

Consider that we have a host A in a site a that has = EID EIDA (which =A0
is globally routable in order to be able to = bootstrap the initial =A0
=A0
Suppose = that site

We have another host B located in a different site b = that has a =A0
another locator RLOCB. Suppose that both site a and = site b has =A0
multiple ISPs (at least two and they have several = TR, for fault =A0
tolerance reasons)

Okay, = first off the hosts don't have locators. The locators are =A0
assigned = to the ETRs.

=
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

No, not = true. ITRB1 prepends an IP header to the host's packet. The =A0
outer SA = is ITRB1's locator address and the outer DA is the EIDA =A0
(copied = from the inner DA). This is only used to trigger a mapping =A0
reply = from the ETR that is responsible for the EID range associated =A0
with = host A. This happens in both LISP 1.0 and LISP 1.5.

the packet reaches the ETRA1 = close to site a and the ETR sends a =A0
ICMP = packet back to the ITRB1 with the RLOCA information and the =A0
mapping = between EIDA and RLOC is stored in ITRB1.

The = source address in the ICMP reply is one of ETRA1's locator =A0
=A0
*EID-prefix* that ETRA1 is responsible for and a = list of all locators =A0
for this = range (and their priority and weight values for each =A0
=A0
ETR in site A.

We have documented this in the = spec.

=
Now bad things start = :-)

Oh good, the meat.

First there is a failure and EIDA is no longer = reachable
No problem with that, since = ITRB1 has the information about =A0
=A0
packets = using RLOCA as dest address in the outer header and the =A0

Ah, no fair, you avoided the real problem. You = didn't even try to ask =A0
how does = ITRB1 know the ETRA1 is not reachable.=A0 ;-)

We do = have answers for them though.=A0 = ;-)

=
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 =A0
is used = for site B, so packets are rerouted to that backup ITRB1 =A0
for site = b.

Yes, of course. There are two ways an ITR determines = a locator is not =A0
reachable:

o It receives an ICMP = Unreachable message.
o It stops seeing packets = it decaps from the EID-prefix range coming =A0
from one = of
=A0=A0 = the locators in the locator-set.

The later is = better and more reliable. And I'm not worrying about =A0
But the = problem is that packets that host b is sending contain EIDA =A0
as = destiantion address which is unfortunatelly unreachable at this =A0
time. = this was not a problem

No, not true. EIDs are always = reachable because they are not location =A0
=A0
locators are not reachable.

before because ITRB1 had the = alternative locator information, but =A0
it has = failed. The backup router ITRB1 does not contain the =A0
=A0
the communication survive this outage?
=

Yes it does. This is not that hard.

I mean, i guess that fault = tolerance is the key feature and the =A0
LISP = boxes cannot become a single point of failure, so i guess it =A0
should = be possible to survive this type of situations

If you = deploy a single ETR, you have a single point of failure. So =A0
you = deploy two of them. And if you have two ISP connections, each ETR =A0
has two = locator addresses, one from each ISP block. Then when the =A0
mapping = is advertised for this site it is done with a single EID-=A0
prefix = advertisement with 4 locators.

See the section in the spec for = locator selection. It is spec'ed to =A0
be = flexible for the ETR to choose what locators the ITR uses, or the =A0
ETR = allows the ITR to choose which ones.

Dino




Subject: confirm = af86831f93db598d55a443098b7a4569dbaf4b59


If you reply = to this message, keeping the Subject: header intact,
Mailman will discard the held message.=A0 Do this if the message = is
spam.=A0 = If you reply to this message and include an Approved: = header
with the list password in it, = the message will be approved for posting
to the = list.=A0 The Approved: = header can also appear in the first line
of the = body of the reply.
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd4KA-0001Xc-U0; Sun, 15 Apr 2007 08:59:22 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd4K9-0001XX-8x for ram@iab.org; Sun, 15 Apr 2007 08:59:21 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd4K8-0006nI-10 for ram@iab.org; Sun, 15 Apr 2007 08:59:21 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 15 Apr 2007 05:59:20 -0700 X-IronPort-AV: i="4.14,412,1170662400"; d="scan'208"; a="687206127:sNHT34549904" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3FCxJJ63686; Sun, 15 Apr 2007 05:59:19 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704151259.l3FCxJJ63686@merlot.juniper.net> To: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: Your message of "Sun, 01 Apr 2007 00:19:15 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <69812.1176641959.1@juniper.net> Date: Sun, 15 Apr 2007 05:59:19 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Tony, > On Mar 31, 2007, at 6:31 PM, Ross Callon wrote: > > > (1) You are going to make the data plane MUCH slower; or > > (2) You are going to very lightly load the data plane; or > > (3) You are going to implement the control aspects of LISP > > somewhere other than on the central processor; or > > (4) You are going to build routers whose central processor is > > several orders of magnitude faster than on current routers; or > > (5) You feel that you can implement LISP on a PE router > > with a load on the control plane which is at least 10,000 > > times smaller than the load on the data plane (so that each > > time a packet goes to the control plane, on the average there > > are 10,000 or more packets that will be forwarded via the data > > plane before the next packet needs to go to the control plane) > > > > I am guessing that the answer is either (5), or perhaps (3), or > > (6) You are going to deploy LISP closer to the edge (and NOT > > in the PE router). > > > If I can paraphrase you, Ross, doing packet forwarding at 10Mpps > doesn't scare me. How many EID-to-RLOC mappings ICMP messages per second an ITR/ETR be required to originate/receive ? Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 09:55:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd59g-0004kZ-GN; Sun, 15 Apr 2007 09:52:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd59f-0004kU-Co for ram@iab.org; Sun, 15 Apr 2007 09:52:35 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd59e-0000W3-5Q for ram@iab.org; Sun, 15 Apr 2007 09:52:35 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 15 Apr 2007 06:52:34 -0700 X-IronPort-AV: i="4.14,412,1170662400"; d="scan'208"; a="708603737:sNHT28502612" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3FDqTJ68343; Sun, 15 Apr 2007 06:52:29 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704151352.l3FDqTJ68343@merlot.juniper.net> To: Tony Li Subject: Re: [RAM] LISP and the Global Internet Architecture In-Reply-To: Your message of "Mon, 02 Apr 2007 18:18:09 PDT." <7D5EA336-B692-4986-83AB-CC518FD066D1@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <70786.1176645149.1@juniper.net> Date: Sun, 15 Apr 2007 06:52:29 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Tony, > >> What do I get over just deploying PI space? > > > > As a customer, nothing. It's not the customers who are going to > > bear the > > pain of widespread PI, it's the ISP's. > > > Hopefully, we will get to the point where identifiers are easier to > justify and use than PI space. One possible mechanism for this is > for providers to stop routing PI space... Let's get some reality check on your suggestion "for providers to stop routing PI space". As Russ pointed out in his e-mail: Which SP is, today, refusing to accept business by way of refusing to advertise PI space? I don't know of any, myself. For the most part, providers are in business to make money, and paying customers are hard to turn away. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 10:07:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd5L6-00024u-Pd; Sun, 15 Apr 2007 10:04:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd5L4-00024p-Vh for ram@iab.org; Sun, 15 Apr 2007 10:04:22 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd5L3-0003zh-N7 for ram@iab.org; Sun, 15 Apr 2007 10:04:22 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 15 Apr 2007 07:04:21 -0700 X-IronPort-AV: i="4.14,412,1170662400"; d="scan'208"; a="687227826:sNHT33554156" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3FE4HJ69443; Sun, 15 Apr 2007 07:04:21 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704151404.l3FE4HJ69443@merlot.juniper.net> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [RAM] LISP and the Global Internet Architecture In-Reply-To: Your message of "Mon, 02 Apr 2007 22:08:25 EDT." <20070403020825.D4A4F872DD@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71028.1176645857.1@juniper.net> Date: Sun, 15 Apr 2007 07:04:17 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Noel, > > From: "Fleischman, Eric" > > > until IPv6 permitted PI addresses, it represented a mechanism that > > required large end users to be held captive to their ISPs. This is > > untenable to any end user and violates a fundamental law of economics > > that businesses support the needs of their customers. > > This was certainly not the intent, or reason, that location-based > addressing was put forward; rather, it was principally motivated by > technical considerations. ("PA" is just a post-hoc label applied to > something that came from technical considerations, hence its original > names - "location-based addressing" or "connectivity-based addressing".) > > You are correct that it had economic consequences that either weren't > adequately considered, or taken into account (or perhaps both), at the > time. > > I think the whole IPv6 experience (and not just the PA/PI thing) has made > us all much more sensitive to the need to try and understand the economics > of the proposed deployment of any new stuff. > > Which leads me to wonder what the future really is, though. What happens > when the IPv4 addresses really do start to run out in a few years? Will we > see a market develop for IPv4 addresses, plus continued use of NAT? Or will > uSoft's attempt to drive IPv6 deployment by including it in Vista succeed? > > And even more importantly, is there really any scope left for good > fundamentals-based engineering, or will we always be restricted by > economic/business considerations to the cheapest thing we can possibly come > up with that more or less kludges the network into continued operation? Whether something is a "kludge" is a matter of (a subjective) opinion. The choice between various options is *not* going to be driven by whether one option is defined by some individuals as "good fundamental-based engineering" vs another option is being defined as a "kludge", but by the cost/benefit analysis between these two options. > Maybe it's time to switch out of networking (or just plain retire and > take up building furniture :-). Unless you willing to go bankrupt, building furniture will not get you out of the cost/benefit analysis :-) Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 10:33:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd5l6-0004AM-Jo; Sun, 15 Apr 2007 10:31:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd5l5-00049l-Gw for ram@iab.org; Sun, 15 Apr 2007 10:31:15 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd5l4-00038N-9s for ram@iab.org; Sun, 15 Apr 2007 10:31:15 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 15 Apr 2007 07:31:14 -0700 X-IronPort-AV: i="4.14,412,1170662400"; d="scan'208"; a="708617656:sNHT26311572" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3FEVDJ71572 for ; Sun, 15 Apr 2007 07:31:13 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704151431.l3FEVDJ71572@merlot.juniper.net> To: ram@iab.org MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <71818.1176647473.1@juniper.net> Date: Sun, 15 Apr 2007 07:31:13 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Subject: [RAM] Researchers Explore Scrapping Internet 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 see http://biz.yahoo.com/ap/070413/rebuilding_the_internet.html?.v=4 _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 10:52:33 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd64b-000324-BQ; Sun, 15 Apr 2007 10:51:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd64Z-00031q-Sr for ram@iab.org; Sun, 15 Apr 2007 10:51:23 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd64Y-0006G1-Mb for ram@iab.org; Sun, 15 Apr 2007 10:51:23 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4D30F872D1; Sun, 15 Apr 2007 10:51:22 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] LISP and the Global Internet Architecture Message-Id: <20070415145122.4D30F872D1@mercury.lcs.mit.edu> Date: Sun, 15 Apr 2007 10:51:22 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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: Yakov Rekhter >> even more importantly, is there really any scope left for good >> fundamentals-based engineering, or will we always be restricted by >> economic/business considerations to the cheapest thing we can possibly >> come up with that more or less kludges the network into continued >> operation? > The choice between various options is *not* going to be driven by > whether one option is defined by some individuals as "good > fundamental-based engineering" vs another option is being defined as a > "kludge", but by the cost/benefit analysis between these two options. IMO, I can express the exact same sentiment, but in purely economic terms - which will take economics out of the equation. So let me do so: Even more importantly, is there really any scope left for design which tries to maximize the cost/benefit integrated over the long term (which almost always means good fundamentals-based engineering), or will we always be restricted by short-term economic/business cost/benefit considerations to the cheapest thing we can possibly come up quickly (which almost equally inevitably means kludging the network into continued operation), even if repeated application of that path choice, over the long term, has a lower overall cost/benefit ratio than the first choice? In other words, looked at in purely economic terms, are you trying to optimize the short-term cost/benefit, or the long-term cost/benefit? Economics alone won't make that choice for you. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 11:53: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 1Hd71K-00029h-AZ; Sun, 15 Apr 2007 11:52:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd71J-00029W-Q2 for ram@iab.org; Sun, 15 Apr 2007 11:52:05 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd71I-0002Q8-GO for ram@iab.org; Sun, 15 Apr 2007 11:52:05 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2007 17:52:00 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3FFpxBF021103; Sun, 15 Apr 2007 17:51:59 +0200 Received: from [212.254.247.3] (ams3-vpn-dhcp176.cisco.com [10.61.64.176]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3FFptlZ002170; Sun, 15 Apr 2007 15:51:55 GMT Message-ID: <46224A1A.5070708@cisco.com> Date: Sun, 15 Apr 2007 17:51:54 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [RAM] LISP and the Global Internet Architecture References: <200704151352.l3FDqTJ68343@merlot.juniper.net> In-Reply-To: <200704151352.l3FDqTJ68343@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=578; t=1176652319; x=1177516319; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=oGUy93hcj7QZ/QtOXS/JTo7Ukr/8+VgziUGRowVUA2M=; b=ceogKmjd/9scn5SeCQJMhCHoMFdDhbh7xX8hbxkbcve7n40IRQsUPIWCmOSVF7ZSGJ/H6ox3 i3Ie8Tufm2TbCl8E6GUCvu18muJ10IWAaFhS7PozWAh62QuEoTsieX+B; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: Tony Li , 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 Yakov, I was with you for a while, but here we differ: Yakov Rekhter wrote: > Let's get some reality check on your suggestion "for providers > to stop routing PI space". As Russ pointed out in his e-mail: > > Which SP is, today, refusing to accept business by way of refusing to > advertise PI space? I don't know of any, myself. For the most part, > providers are in business to make money, and paying customers are hard > to turn away. > They have no alternative to offer their customers today, so this question is entirely irrelevant. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 12:33:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd7eg-0002je-Bv; Sun, 15 Apr 2007 12:32:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hd7ee-0002jU-Ev for ram@iab.org; Sun, 15 Apr 2007 12:32:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hd7ed-000890-61 for ram@iab.org; Sun, 15 Apr 2007 12:32:44 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 15 Apr 2007 18:32:36 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3FGWacE026341; Sun, 15 Apr 2007 18:32:36 +0200 Received: from [212.254.247.3] (ams3-vpn-dhcp176.cisco.com [10.61.64.176]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3FGWVlZ007115; Sun, 15 Apr 2007 16:32:32 GMT Message-ID: <4622539F.8010304@cisco.com> Date: Sun, 15 Apr 2007 18:32:31 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <200704151259.l3FCxJJ63686@merlot.juniper.net> In-Reply-To: <200704151259.l3FCxJJ63686@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=254; t=1176654756; x=1177518756; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=7QbYpVZtldjOGxtgovgZpGgnlW1/7RSuDr9rdMJ72mM=; b=j4Yyb5h7LQCCyuMli7gkBK1VEPjT9aVfN4hcT0BLcOXEw5s4EPtkpBbxAGzU1cE6XG18djBX oaymPGcvu9xlK2aLxEoI7C9x7WjxWfuCuH5n5kDWLhtOKh0Io7eSScxi; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Tony Li , 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 Yakov Rekhter wrote: > How many EID-to-RLOC mappings ICMP messages per second an ITR/ETR be > required to originate/receive ? > Doesn't that very much depend where the ITR/ETR sits? And isn't the point of an experiment to find out? Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 16:38:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdBSp-0006DH-Hu; Sun, 15 Apr 2007 16:36:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdBSo-0006DC-Gj for ram@iab.org; Sun, 15 Apr 2007 16:36:46 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdBSo-0008Ux-5q for ram@iab.org; Sun, 15 Apr 2007 16:36:46 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 15 Apr 2007 13:36:41 -0700 X-IronPort-AV: i="4.14,413,1170662400"; d="scan'208"; a="136183092:sNHT54043326" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id l3FKafHd032239; Sun, 15 Apr 2007 13:36:41 -0700 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 l3FKaeEi022755; Sun, 15 Apr 2007 20:36:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:36:40 -0700 Received: from [192.168.0.100] ([10.21.98.94]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 13:36:40 -0700 In-Reply-To: <46224A1A.5070708@cisco.com> References: <200704151352.l3FDqTJ68343@merlot.juniper.net> <46224A1A.5070708@cisco.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: Tony Li Subject: Re: [RAM] LISP and the Global Internet Architecture Date: Sun, 15 Apr 2007 13:36:39 -0700 To: Eliot Lear X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Apr 2007 20:36:40.0456 (UTC) FILETIME=[C5911080:01C77F9D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1758; t=1176669401; x=1177533401; c=relaxed/simple; s=sjdkim3002; 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]=20LISP=20and=20the=20Global=20Internet=20Archit ecture |Sender:=20; bh=nmrX78UoHo+FNI4kehjuOiRV35Y8vUvjVSZaaafZ67w=; b=XICCxe75CXG2ZzNTJT664V1iZmdVzuuT0HSNUya3Y3GNxr7Gh0PdY8R7GhFAecyDnnNeaUYB iyFqFZGCne4+zMdY9uVA+bmhvzwOJhxfbKJqbsr92npndSh7NyuwRmON; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: RAM 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 Apr 15, 2007, at 8:51 AM, Eliot Lear wrote: > Yakov Rekhter wrote: >> Let's get some reality check on your suggestion "for providers >> to stop routing PI space". As Russ pointed out in his e-mail: >> >> Which SP is, today, refusing to accept business by way of >> refusing to >> advertise PI space? I don't know of any, myself. For the most part, >> providers are in business to make money, and paying customers >> are hard >> to turn away. >> > > They have no alternative to offer their customers today, so this > question is entirely irrelevant. I mostly agree with Eliot here. However, we can also look at the economics of the longer term view. Suppose that we reach a state where we have an adequate and beneficial ID/locator split deployed. I believe that we've already discussed the benefits to the ISP for simply having the singly-homed customer using ID/locator (i.e., ease of moving the customer topologically, without customer renumbering). That is a benefit to the ISP. For a multi-homed customer, the ISP can either accept a PI prefix and deal with the overhead (management of route filters, BGP session maintenance, etc.) or the ISP can assign a locator. Now, I'm sure that if the ISP is offered sufficient amounts of money, they can be persuaded to advertise the PI. However, for them, that would seem to be the operational exception. From the customer point of view, the ease of renumbering is the primary benefit, coupled with the removal of the pain of having to justify their PI prefix. Thus, if we do our jobs properly, we should end up in a situation where all parties are economically motivated to deploy an ID/locator split. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sun Apr 15 17:20: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 1HdC80-0005Nm-5h; Sun, 15 Apr 2007 17:19:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdC7z-0005Ng-Ee for ram@iab.org; Sun, 15 Apr 2007 17:19:19 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdC7y-0003aQ-4y for ram@iab.org; Sun, 15 Apr 2007 17:19:19 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 15 Apr 2007 14:18:13 -0700 X-IronPort-AV: i="4.14,413,1170662400"; d="scan'208"; a="411669611:sNHT45643360" 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 l3FLIDsn024524; Sun, 15 Apr 2007 14:18:13 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id l3FLIDA8013147; Sun, 15 Apr 2007 21:18:13 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 14:18:13 -0700 Received: from [192.168.0.100] ([10.21.98.94]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 15 Apr 2007 14:18:12 -0700 In-Reply-To: <200704151259.l3FCxJJ63686@merlot.juniper.net> References: <200704151259.l3FCxJJ63686@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <59B10549-F99C-465C-8A2A-DEF30CD99261@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Sun, 15 Apr 2007 14:18:11 -0700 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 15 Apr 2007 21:18:12.0612 (UTC) FILETIME=[9301E440:01C77FA3] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=662; t=1176671893; x=1177535893; c=relaxed/simple; s=sjdkim8002; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP)=20 |Sender:=20; bh=YgQzJ/n3hD1P8UwsWcupiGKUo5bc1IeucWxtvLXQqOg=; b=Nne17p/IwszXTJPy+YAC958B0l1KWixKzDz/1+dVKbfSeq57zplmWQIV38WoBcrwY71umANe SUfR+ixUcK48ypUqomvAMoVgIC8/yXantFbvSHqGxZ0O8AvtRP3x/aF3; Authentication-Results: sj-dkim-8; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 Apr 15, 2007, at 5:59 AM, Yakov Rekhter wrote: >> If I can paraphrase you, Ross, doing packet forwarding at 10Mpps >> doesn't scare me. > > How many EID-to-RLOC mappings ICMP messages per second an ITR/ETR be > required to originate/receive ? Yakov, I think that you're confusing the encap rate with the mapping rate. Assuming that we eventually get the mapping mechanism correct (which admittedly may require LISP version N for arbitrarily large N ;-), then some low message rate, asymptotically approaching 0 pps should be required. The precedent here is the overhead required by a site's local caching DNS server. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 02:36:06 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKoh-0002sh-BX; Mon, 16 Apr 2007 02:35:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdKof-0002sU-EP for ram@iab.org; Mon, 16 Apr 2007 02:35:57 -0400 Received: from rtp-iport-2.cisco.com ([64.102.122.149]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdKoc-0008JW-Uo for ram@iab.org; Mon, 16 Apr 2007 02:35:57 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Apr 2007 02:35:54 -0400 X-IronPort-AV: i="4.14,413,1170651600"; d="scan'208"; a="118597094:sNHT54976144" Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3G6Zs6S007959; Mon, 16 Apr 2007 02:35:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3G6ZiGd008881; Mon, 16 Apr 2007 06:35:45 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 02:35:44 -0400 Received: from [192.168.0.4] ([10.82.209.164]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 02:35:44 -0400 In-Reply-To: <462059BB.10309@firstpr.com.au> References: <462059BB.10309@firstpr.com.au> 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] How does LISP recognise which IP addresses to query mapping for? Date: Sun, 15 Apr 2007 23:35:44 -0700 To: Robin Whittle X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Apr 2007 06:35:44.0239 (UTC) FILETIME=[75BB17F0:01C77FF1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4971; t=1176705354; x=1177569354; c=relaxed/simple; s=rtpdkim2001; 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]=20How=20does=20LISP=20recognise=20which=20IP=20 addresses=20to=20query=20mapping=20for? |Sender:=20 |To:=20Robin=20Whittle=20; bh=YwU1PzDHeOYi1xPFe8JCMupEqUofr8eLy05/lh3kZwM=; b=yZqdwoDBD8+sa0clNu5sDvEoD8Qo4S9JPlw+9xOGLvZmT67nD5M7GT0NwOEUjigRiBQ7HD2K smUyMGtnLGp+ZmMXl5d6fiHCjq9yH/OQkAdbdH+waucFqm6jlgsYJNLS; Authentication-Results: rtp-dkim-2; header.From=dino@cisco.com; dkim=pass (s ig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 an IPv4 setting, assuming the current /24 granularity of whether > the addresses are advertised in BGP or not, I am curious about how a > LISP implementation would handle packets which were addressed to > addresses not advertised in BGP. Not clear what your question here is. You could be saying how does LISP encapsulate a packet when received with a DA that is not in BGP. Or what happens when LISP tries to encapsulate with a locator address that is not in BGP. If the former, that would be the PI case situation. Which means, you go get the mapping and until you get it, you don't forward packets. Or you do a LISP 1.5 and route the packet with the PI address on another topology that does carry the address in routing (but not in the BGP core). If the later, then it is a misconfiguration. An ETR must be reachable via the BGP core. The ETR possesses a locator address. > I don't see how LISP 1 helps reduce the load of growing numbers of > prefixes in the BGP routing system. I find it hard to imagine the It doesn't. It's a phase 0 prototype effort. > development of a global alternative routing system for LISP 1.5 and It is a simpler one since the advertisement of EID-prefixes are free of topological or policy constraints. So better aggregation can be achieved with very low entropy. > I don't see how LISP 1.5 could be deployed incrementally, since the > alternative routing system would need to be in place and LISP > routers would need to be in practically every edge network, to > ensure continued universal reachability of any addresses which were > taken out of the BGP system and accessed as LISP EIDs instead. It is done incrementally because if you route to a destination site which is not LISP enabled, the ITR in the source site which is LISP- enabled, will not learn a mapping so it will not encapsulate the packet and send it natively like it does today. > I think LISP 2 or 3 could have significant benefits, but I think > they too would require a complete upgrade, since no-one would want What do you mean by complete? > to make their IP addresses inaccessible to the fraction of edge > networks which had not installed LISP routers. (Unless there is a > way of catching the packets in the DFZ, with special LISP routers - > but then someone would need to pay for that, when it should be the > responsibility of each edge network to pay for its own LISP > capabilities.) In the transition case, where a new site still needs to put their routes in the BGP-core, the site still gets ingress traffic engineering. So it's not just one problem we are focusing on. > I am mainly thinking of a complete upgrade, over 5 or so years, to > border routers and transit routers, with SRAM forwarding in border > and transit routers and LISP 2/3 functions in the border routers and > perhaps in routers within the edge networks. However, the questions > below assume only LISP 2 or 3, not SRAM forwarding. Regardless of the type of forwarding engine you have, if an EID- prefix is put in what we know today as the FIB, and the next-hop encapsulation is IP-in-IP, we can forward LISP encapsulated packets today in hardware. We can do this with GRE and L2TPv3 in shipping routers today. > Here is why I think the central database needs to be able to tell > the ITR a definite "No" if the requested IP address is not mapped by > the LISP system, and to tell the ITR the prefix which this address > is part of, for which the same answer applies. (I assume that a > response returning mapping would also indicate the enclosing prefix, > as with the 5 bit EID Mask length and 32 bit EID prefix in the > draft-farinacci-lisp-00.) Sure, this can be done. > I also think there needs to be a TTL or similar - to tell the ITR > how long to cache this information for. (I don't see a TTL in the > ICMP "Control-Plane Packet Format in draft-farinacci-lisp-00 - but > it strikes me that one would be desirable.) Yes, we will add this in the next draft. With a query/reply protocol, we need a TTL. With a push protocol, we may not need one. > It sends a request to the database. If the only way the database > can answer "No" is to not respond, then the ITR has to record that > this particular IP address has no LISP mapping, so the packet should > be dropped. However, the ITR also needs to remember this for that > IP address, for some configurable time, to prevent it repeating the > query when another packet arrives for this address. The amount of > state to be stored could get out of hand if it was repeated on a > large number of IP addresses, as would happen with a user scanning a > large number of IP addresses for some reason. It has been suggested, to avoid these class or problems, is to have the ISP deploy a proxy LISP ETR on behalf a sites that do not have LISP enabled. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 08:36:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQRN-00027v-QD; Mon, 16 Apr 2007 08:36:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdQRM-00027p-VT for ram@iab.org; Mon, 16 Apr 2007 08:36:16 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdQRL-0002TG-O5 for ram@iab.org; Mon, 16 Apr 2007 08:36:16 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 16 Apr 2007 05:36:15 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="687707567:sNHT30003768" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3GCaFJ34923; Mon, 16 Apr 2007 05:36:15 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704161236.l3GCaFJ34923@merlot.juniper.net> To: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP In-Reply-To: Your message of "Fri, 13 Apr 2007 10:44:22 PDT." MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <12222.1176726975.1@juniper.net> Date: Mon, 16 Apr 2007 05:36:15 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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, > >>> This would be an good example to illustrate that LISP 1.5 offer > >>> *no* reduction of the volume of routing information. To the > >>> contrary, > >>> this example would illustrate how LISP 1.5 would result in > >>> increasing > >>> volume of routing information. > >> > >> It reduces the unicast FIB. > > > > Any *empirical* evidences to support the above claim would be greatly > > appreciated. > > The point is that the PI prefixes which are in the core today can be > removed because they will be routed on another, smaller topology, to > be used to probe for locator replies. Would that still reduce the unicast FIB on the routers that participate in the "smaller topology" ? Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 09:26:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRDr-0002Gl-OW; Mon, 16 Apr 2007 09:26:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRDq-0002Gd-7c for ram@iab.org; Mon, 16 Apr 2007 09:26:22 -0400 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 1HdRDn-0002Sd-TZ for ram@iab.org; Mon, 16 Apr 2007 09:26:22 -0400 Received: from blv-av-01.boeing.com (blv-av-01.boeing.com [192.42.227.216]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3GDQIr5006560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Apr 2007 08:26:19 -0500 (CDT) 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 l3GDQI3L023549; Mon, 16 Apr 2007 06:26:18 -0700 (PDT) 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 l3GDQHQw023546; Mon, 16 Apr 2007 06:26:18 -0700 (PDT) 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); Mon, 16 Apr 2007 06:26:14 -0700 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] Fwd: RAM post from dino@cisco.com requires approval Date: Mon, 16 Apr 2007 06:26:13 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FA@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <332DD4CB-6026-48AC-8176-4D9DD29A6C3D@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Fwd: RAM post from dino@cisco.com requires approval Thread-Index: Acd+HyCVbGKFPrnjQ7iKMBqwVsjQTgCCzckw References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu><639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com><51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com><348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> <332DD4CB-6026-48AC-8176-4D9DD29A6C3D@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" , "Chris L. Morrow" X-OriginalArrivalTime: 16 Apr 2007 13:26:14.0292 (UTC) FILETIME=[CE62ED40:01C7802A] X-Spam-Score: 1.4 (+) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 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 may be missing the point of this, but in a LISP 2/3 world why couldn't it be that all customers (large and small) could get PI prefixes if they wanted them? The PI identifiers are not carried in the core, so there is no strong requirement for hierarchical aggregation, right? Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Friday, April 13, 2007 3:57 PM > To: Chris L. Morrow > Cc: ram@iab.org > Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval >=20 > >>> > >>> Don't you think this process can change if we had a locator-id > >>> split? That is the site would only advertise the blocks you gave > >>> them back to you and no where else. Even if they didn't=20 > follow this > >>> process, you could still aggregate. Would this help on the core =20 > >>> side? > >> > >> The BGP policy may not change, so we may still not want to=20 > aggregate > >> bgp announcement. The key difference will be that=20 > customer will not > >> need BGP in order to multihome. Teaching customers that=20 > they do not > >> need BGP to multihome may become a difficult education process. > > > > there is also the issue of what 'size' customer... a=20 > smaller site that > > doesn't have 'PI' space (locator space) may not (will not=20 > depending =20 > > on the > > split) need bgp at all. A larger site that justifies/needs/pays-=20 > > for 'PI' > > (locator) space will still do BGP and participate in the 'DFZ'. >=20 > Well, you could take a PI advertisement from the site but deploy an =20 > ITR on your PE so the PI can stop there. Not sure what your=20 > incentive =20 > is to do so though. I guess if they pay you big dollars for PI, the =20 > cost will be a bit more for you to manage the non-pollution of it. >=20 > Dino >=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 Apr 16 09:32:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRJw-0004ad-Su; Mon, 16 Apr 2007 09:32:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRJv-0004aS-OC for ram@iab.org; Mon, 16 Apr 2007 09:32:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRJu-0004OW-Fw for ram@iab.org; Mon, 16 Apr 2007 09:32:39 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 16 Apr 2007 06:32:38 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="687741005:sNHT37709292" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3GDWbJ44532; Mon, 16 Apr 2007 06:32:37 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704161332.l3GDWbJ44532@merlot.juniper.net> To: Tony Li Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: Your message of "Sun, 15 Apr 2007 14:18:11 PDT." <59B10549-F99C-465C-8A2A-DEF30CD99261@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <15862.1176730357.1@juniper.net> Date: Mon, 16 Apr 2007 06:32:37 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Tony, > On Apr 15, 2007, at 5:59 AM, Yakov Rekhter wrote: > > >> If I can paraphrase you, Ross, doing packet forwarding at 10Mpps > >> doesn't scare me. > > > > How many EID-to-RLOC mappings ICMP messages per second an ITR/ETR be > > required to originate/receive ? > > > Yakov, > > I think that you're confusing the encap rate with the mapping rate. Incorrect. > Assuming that we eventually get the mapping mechanism correct (which > admittedly may require LISP version N for arbitrarily large N ;-), > then some low message rate, asymptotically approaching 0 pps should > be required. My question was in the context of LISP 1.5. > The precedent here is the overhead required by a site's > local caching DNS server. The analogy does not hold. This is because DNS does not provide any information about whether a particular host is reachable or not. In contrast, in LISP the ICMP messages do provide reachability/unreachability information about RLOCs. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 09:32:51 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRK7-0004fc-8O; Mon, 16 Apr 2007 09:32:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdRK6-0004fW-5s for ram@iab.org; Mon, 16 Apr 2007 09:32:50 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdRK3-0004S0-CS for ram@iab.org; Mon, 16 Apr 2007 09:32:50 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3GDWkV7012940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 16 Apr 2007 06:32:46 -0700 (PDT) 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 l3GDWk95010063 for ; Mon, 16 Apr 2007 06:32:46 -0700 (PDT) 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 l3GDWV2w009652 for ; Mon, 16 Apr 2007 06:32:45 -0700 (PDT) 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); Mon, 16 Apr 2007 06:32:42 -0700 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: Mon, 16 Apr 2007 06:32:42 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <200704161236.l3GCaFJ34923@merlot.juniper.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: 6to4 Thread-Index: AceAI/OKpGis4y3/Ro6NCJP1qqAhRQABt35A References: Your message of "Fri, 13 Apr 2007 10:44:22 PDT." <200704161236.l3GCaFJ34923@merlot.juniper.net> From: "Templin, Fred L" To: X-OriginalArrivalTime: 16 Apr 2007 13:32:43.0156 (UTC) FILETIME=[B62ADD40:01C7802B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [RAM] 6to4 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 am wondering where 6to4 fits on the LISP continuum. Correct me if I am wrong, but with 6to4 the identifer to locator mapping comes from a single DNS lookup. The identifer is not routeable over the core, but the ETR locator is embedded in the identifier address so the ETR discovery comes "for free". Is 6to4 an example of LISP 2? Is it good enough to be considered as a long-term solution, or is it just a baby-step to a fully jacked-up LISP deployment? Thanks - 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 Mon Apr 16 10:47: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 1HdSU6-00074y-8w; Mon, 16 Apr 2007 10:47:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSU5-00074r-69 for ram@iab.org; Mon, 16 Apr 2007 10:47:13 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSU2-0005Ut-Vq for ram@iab.org; Mon, 16 Apr 2007 10:47:13 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 4B9E1872F4; Mon, 16 Apr 2007 10:47:04 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Message-Id: <20070416144704.4B9E1872F4@mercury.lcs.mit.edu> Date: Mon, 16 Apr 2007 10:47:04 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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: Yakov Rekhter > My question was in the context of LISP 1.5. Dino just mentioned how LISP 1 is a "phase 0 prototype effort", and I suspect the same is true, in some ways, of many of the lower numbered LISP variants. My sense is that the one that gets deployed in large-scale operational service is likely to be LISP 4 or 5 (or more), i.e. one that's not yet defined. My guess is that the architectural commonality between LISP 1/1.5/etc and the eventual deployed stuff is likely to be: - Hosts and local routers don't need to be modified - The existing internetwork layer is "jacked up" to become mostly an end-end host naming layer - End-end names are mapped into new locators as they cross the boundary I think LISP is the first detailed proposal in the last half-decade or so to propose operating in this particular architectural quadrant (which may well be the only feasible one to operate in), and I suspect that's why it's getting a lot of attention. However, the final product may look quite different from the initial prototypes we have on paper now. The current discussion seems to be a somewhat unfocussed mix of "can we operate in this quadrant at all", and details of particular variants, trying to sort of which particular approach (within the boundary lines above) works; most of the current discussion is, of course, looking at how to do the mapping, which is appropriate, because that's probably the hardest part. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 10:59:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSgD-0002Kd-40; Mon, 16 Apr 2007 10:59:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdSgA-0002KA-Qu for ram@iab.org; Mon, 16 Apr 2007 10:59:43 -0400 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdSg9-0001KI-Dr for ram@iab.org; Mon, 16 Apr 2007 10:59:42 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l3GExeQZ095336 for ; Mon, 16 Apr 2007 14:59:40 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.3) with ESMTP id l3GExe752728028 for ; Mon, 16 Apr 2007 15:59:40 +0100 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 l3GExeBx003413 for ; Mon, 16 Apr 2007 15:59:40 +0100 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 l3GExdWc003403; Mon, 16 Apr 2007 15:59:40 +0100 Received: from [9.146.218.11] (chv02261.de.ibm.com [9.146.218.11]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id QAA326142; Mon, 16 Apr 2007 16:59:38 +0200 Message-ID: <46238F5E.4070302@zurich.ibm.com> Date: Mon, 16 Apr 2007 16:59:42 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [RAM] 6to4 References: Your message of "Fri, 13 Apr 2007 10:44:22 PDT." <200704161236.l3GCaFJ34923@merlot.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 On 2007-04-16 15:32, Templin, Fred L wrote: > I am wondering where 6to4 fits on the LISP continuum. > Correct me if I am wrong, but with 6to4 the identifer > to locator mapping comes from a single DNS lookup. The > identifer is not routeable over the core, but the ETR > locator is embedded in the identifier address so the > ETR discovery comes "for free". > > Is 6to4 an example of LISP 2? Well, it was conceived rather differently, on a model where there is exactly one IPv4 core, exactly one native IPv6 cloud, and a large number of IPv6 islands wishing to communicate with the IPv6 cloud over the IPv4 core. If you use it otherwise, it is not a method that will limit expansion of the IPv6 DFZ, and it does absolutely nothing for the IPv4 DFZ. > Is it good enough to be > considered as a long-term solution, or is it just a > baby-step to a fully jacked-up LISP deployment? I'd rather view it as a subversive technology that has a finite scope of applicability. Of course, within that scope, the 6to4 mapping is a perfectly fine one for an IPv6-over-IPv4 implementation of LISP. But I doubt it can be the only mapping in use. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 11:23: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 1HdT2r-0003t7-KT; Mon, 16 Apr 2007 11:23:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdT2q-0003t0-K1 for ram@iab.org; Mon, 16 Apr 2007 11:23:08 -0400 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 1HdT2o-0003Bf-A9 for ram@iab.org; Mon, 16 Apr 2007 11:23:08 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3GFN41x017692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 16 Apr 2007 08:23:05 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3GFN4dW023109; Mon, 16 Apr 2007 10:23:04 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3GFMvWC022694; Mon, 16 Apr 2007 10:23:04 -0500 (CDT) 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); Mon, 16 Apr 2007 08:22:58 -0700 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] 6to4 Date: Mon, 16 Apr 2007 08:22:58 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED700@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <46238F5E.4070302@zurich.ibm.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] 6to4 Thread-Index: AceAN+CKGig0Lk2MRjWkj4fFJAAYdgAAnuBg References: Your message of "Fri, 13 Apr 2007 10:44:22 PDT." <200704161236.l3GCaFJ34923@merlot.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.nw.nos.boeing.com> <46238F5E.4070302@zurich.ibm.com> From: "Templin, Fred L" To: "Brian E Carpenter" X-OriginalArrivalTime: 16 Apr 2007 15:22:59.0116 (UTC) FILETIME=[1D963EC0:01C7803B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 Brian, > I'd rather view it as a subversive technology that > has a finite scope of applicability. I was somewhat surprised to see the word "subversive" here, but that would be consistent with my emerging understanding of how new Internet architectures move forward (or don't). Can we count on Microsoft Vista and others to be vehicles for carrying new Internet architectures forward? Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 12:09:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTm3-0005iw-F4; Mon, 16 Apr 2007 12:09:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTm2-0005il-Dp for ram@iab.org; Mon, 16 Apr 2007 12:09:50 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdTm1-0007Ma-4B for ram@iab.org; Mon, 16 Apr 2007 12:09:50 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-4.cisco.com with ESMTP; 16 Apr 2007 09:09:48 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="53816175:sNHT81976095" 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 l3GG9mmL001155; Mon, 16 Apr 2007 09:09:48 -0700 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 l3GG8oxN028651; Mon, 16 Apr 2007 16:09:48 GMT 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, 16 Apr 2007 09:09:44 -0700 Received: from [192.168.0.4] ([10.21.117.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 09:09:44 -0700 In-Reply-To: <200704161236.l3GCaFJ34923@merlot.juniper.net> References: <200704161236.l3GCaFJ34923@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6F69ABA8-3B38-42D0-B3C3-A993077750AF@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Incremental Deployment of LISP Date: Mon, 16 Apr 2007 09:09:44 -0700 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Apr 2007 16:09:44.0365 (UTC) FILETIME=[A5A545D0:01C78041] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1004; t=1176739788; x=1177603788; 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]=20Incremental=20Deployment=20of=20LISP=20 |Sender:=20; bh=x9lMkItQL0R2BaWP2l/BX1MHvbZzQ9YWwvGSnQA/kco=; b=iQfTsUUJjRbCMlTraf0tavSjcnEZZfVBUKUGyKNrWfZ1o2V/lsY/nTlVXvXRK5kQvDv75/Il l0TthvJr4N8Xs49mqnzuCOrUh2fl55W9GtUvQpU1bN0MP6UOv01B6gf0; 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: 2409bba43e9c8d580670fda8b695204a 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 would be an good example to illustrate that LISP 1.5 offer >>>>> *no* reduction of the volume of routing information. To the >>>>> contrary, >>>>> this example would illustrate how LISP 1.5 would result in >>>>> increasing >>>>> volume of routing information. >>>> >>>> It reduces the unicast FIB. >>> >>> Any *empirical* evidences to support the above claim would be >>> greatly >>> appreciated. >> >> The point is that the PI prefixes which are in the core today can be >> removed because they will be routed on another, smaller topology, to >> be used to probe for locator replies. > > Would that still reduce the unicast FIB on the routers that > participate > in the "smaller topology" ? It could a bit because of the better aggregation. But, again, the result is a smaller FIB in more routers. Only the LISP routers will have the same or smaller FIB than a core router. Plus, if the FIB is on-demand, then the size is based on current usage. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 12:14:40 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTqi-00081T-4o; Mon, 16 Apr 2007 12:14:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdTqg-00080z-Gj for ram@iab.org; Mon, 16 Apr 2007 12:14:38 -0400 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 1HdTqf-0008Jr-6V for ram@iab.org; Mon, 16 Apr 2007 12:14:38 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2007 09:14:36 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="478520670:sNHT50058284" 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 l3GGEYXk023513; Mon, 16 Apr 2007 09:14:34 -0700 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 l3GGELZh014024; Mon, 16 Apr 2007 16:14:34 GMT 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, 16 Apr 2007 09:14:33 -0700 Received: from [192.168.0.4] ([10.21.117.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 09:14:33 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FA@XCH-NW-7V2.nw.nos.boeing.com> References: <8F8E726B-D5F2-45B2-AF7F-10D901E74C05@cs.ucla.edu><639879EC-1488-4DFF-AA4D-1FCD46F6BE3D@cisco.com><51FC9304-A2B7-4CB0-A449-8C23F2E6A6DF@lugs.com><348449A1-6A85-446E-A238-B78AD26F703C@cisco.com> <332DD4CB-6026-48AC-8176-4D9DD29A6C3D@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FA@XCH-NW-7V2.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: <377FCCA2-111E-499A-9309-9DB7904A42FD@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Fwd: RAM post from dino@cisco.com requires approval Date: Mon, 16 Apr 2007 09:14:33 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Apr 2007 16:14:33.0599 (UTC) FILETIME=[520AE0F0:01C78042] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=428; t=1176740074; x=1177604074; 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]=20Fwd=3A=20RAM=20post=20from=20dino@cisco.com=2 0requires=20approval |Sender:=20; bh=ezv7Hvd3QwhwYkHjJw60QVibEF91gne8OCnbzwUuLaU=; b=CNpGnKv4ysiFdywD+0+puwxgqdyt2N4+leeSaAe8kICqjBT0yOCHVB9GCkwKqqMX+Jj48AgD TNtP5RKdqUQh5RJl5cFXLQiCRDUtIHyt4bEF6k/JzOUOnHfEwGzKJbXueSzsZvmOs7NB+EYqgd J7k9Ii3lPCT+RYUnpgj+zncdk=; 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: 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 > I may be missing the point of this, but in a LISP 2/3 world > why couldn't it be that all customers (large and small) could > get PI prefixes if they wanted them? The PI identifiers are > not carried in the core, so there is no strong requirement > for hierarchical aggregation, right? To make distribution of the mapping entires scale, you don't want to send them everywhere, bandwidth-vs-memory tradeoff. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 12:28: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 1HdU3o-00047q-Vc; Mon, 16 Apr 2007 12:28:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdU3m-00047k-UW for ram@iab.org; Mon, 16 Apr 2007 12:28:10 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdU3l-0005ZF-3T for ram@iab.org; Mon, 16 Apr 2007 12:28:10 -0400 Received: from sj-dkim-7.cisco.com ([171.68.10.88]) by sj-iport-5.cisco.com with ESMTP; 16 Apr 2007 09:28:08 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="411945187:sNHT49676520" 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 l3GGS8YB015149; Mon, 16 Apr 2007 09:28:08 -0700 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 l3GGS7wn007642; Mon, 16 Apr 2007 16:28:07 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 09:28:07 -0700 Received: from [192.168.0.4] ([10.21.117.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 09:28:07 -0700 In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.nw.nos.boeing.com> References: Your message of "Fri, 13 Apr 2007 10:44:22 PDT." <200704161236.l3GCaFJ34923@merlot.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.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: <7BD4CF97-E5C7-46F3-8091-19AA750BE3A4@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] 6to4 Date: Mon, 16 Apr 2007 09:28:07 -0700 To: "Templin, Fred L" X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Apr 2007 16:28:07.0490 (UTC) FILETIME=[3728CA20:01C78044] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1604; t=1176740888; x=1177604888; 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]=206to4 |Sender:=20; bh=2mzk6KJNha3/fDKASGtUbwlSuOPIQIGA/5EmRAsYHwo=; b=ZPwndYmLC25bt9Uexw3dSpDxRMjfYoYxnCslLDLP+sgb7cuovCAZxZH/sdtpKIiOoVRHjeWs ZXx/3YuG55hA1AMIPwmIYEeaK+1bU4NtBvpEjUU8DjVRwR9rHdt0sGj4; 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: 9ed51c9d1356100bce94f1ae4ec616a9 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 am wondering where 6to4 fits on the LISP continuum. Well, it can work serially. Here is the scenario I am referring to: o An IPv6 packet is received by an ITR. o The DA is an EID so a mapping lookup is done to yield a locator in the 2002::/16 range. o The ITR prepends a IPv6 header. o The platform specific code in the router will try to resolve a next- hop and find out there is no IPv6 next-hop for the outer DA. So it resolves the address to an IPv4 address which follows the 2002 bits. The ITR prepends an IPv4 header. o The ITR sends the packet out the interface where the IPv4 DA is resolved to. > Correct me if I am wrong, but with 6to4 the identifer > to locator mapping comes from a single DNS lookup. The > identifer is not routeable over the core, but the ETR > locator is embedded in the identifier address so the > ETR discovery comes "for free". The EID in DNS could be a 2002::/16 prefix, but it shouldn't assume the address itself or the IPv4 embedded in it is routable. > Is 6to4 an example of LISP 2? Is it good enough to be Well you can put 2002 addresses in DNS. So from a LISP point of view, it just a mapping lookup on a string of bits. > considered as a long-term solution, or is it just a > baby-step to a fully jacked-up LISP deployment? If you used IPv6 addresses as EIDs and IPv4 addresses as locators, then the 6to4 step would be an extra one you would not need. And I wouldn't want to use it because it adds an additional 20 bytes to the packet (as described from the sequence above). Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 12:31:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdU76-0005ZJ-Ba; Mon, 16 Apr 2007 12:31:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdU74-0005ZC-Iy for ram@iab.org; Mon, 16 Apr 2007 12:31:34 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdU72-0006en-QV for ram@iab.org; Mon, 16 Apr 2007 12:31:34 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 16 Apr 2007 18:31:30 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3GGVU6x017721; Mon, 16 Apr 2007 18:31:30 +0200 Received: from [212.254.247.3] (ams3-vpn-dhcp4652.cisco.com [10.61.82.43]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3GGVPlZ004544; Mon, 16 Apr 2007 16:31:29 GMT Message-ID: <4623A4DD.7030009@cisco.com> Date: Mon, 16 Apr 2007 18:31:25 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <20070416144704.4B9E1872F4@mercury.lcs.mit.edu> In-Reply-To: <20070416144704.4B9E1872F4@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1018; t=1176741090; x=1177605090; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=jjI/0hZxlBisj6/hZBmaXXmfbA6w2QLERUU9wpflDbE=; b=cOM7U98VF6u0BO6WnTcf+F6qaRIBFQUloz8k99PWBb1o9S15kCzUwK0+Om+Uj+4o3PBF4g1b WPBdJ4yzQk4AC21VWJpOA5v9F55lAYPUcf2OrtsDuT/p/nHjZNInrnkb; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); 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 Hi Noel, > The current discussion seems to be a somewhat unfocussed mix of "can we > operate in this quadrant at all", and details of particular variants, trying > to sort of which particular approach (within the boundary lines above) works; > most of the current discussion is, of course, looking at how to do the > mapping, which is appropriate, because that's probably the hardest part. > There are two issues. First, in order to figure out whether "we can operate in this quandrant at all", you're of course correct that we need to understand the details to some reasonable degree. But I think there is another question that is nagging at each step, which is what precisely are the scaling characteristics that we are targeting? If we disagree on those points we will surely disagree on the different proposals that make differing assumptions. And so it's probably not unwise to question, for instance, the number of mappings needed. Now seems like a good time for that. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 13:10:04 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUiD-00025j-J3; Mon, 16 Apr 2007 13:09:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdUg7-0000qA-9b for ram@iab.org; Mon, 16 Apr 2007 13:07:47 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdUaN-0003nc-Bw for ram@iab.org; Mon, 16 Apr 2007 13:01:51 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 16 Apr 2007 10:01:50 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="136429754:sNHT51649290" 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 l3GH1olN021911; Mon, 16 Apr 2007 10:01:50 -0700 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 l3GH1YFE005404; Mon, 16 Apr 2007 17:01:48 GMT 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); Mon, 16 Apr 2007 10:01:43 -0700 Received: from [192.168.0.4] ([10.21.117.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 16 Apr 2007 10:01:42 -0700 In-Reply-To: <20070416144704.4B9E1872F4@mercury.lcs.mit.edu> References: <20070416144704.4B9E1872F4@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: <773A9F70-2BC6-4B4D-9ABE-A154776C695C@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Mon, 16 Apr 2007 10:01:43 -0700 To: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 16 Apr 2007 17:01:42.0818 (UTC) FILETIME=[E8637020:01C78048] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2776; t=1176742910; x=1177606910; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=MdVB3/YNfPuRY0T7uhODQfXlsuqScfvpWpp0EOVCH2M=; b=Io7cycKBRI+LKd2l4zbg6aZu4dQVll3t6m+9+vpL4BRtUYxibKqHxez1/6yRK4WeOi3DabTO mfshJ8WjFkZJtAyxK+mzcjOJp+lCFexXGctw+nTeMx8WH5u6sjVa/GEK; 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: 00e94c813bef7832af255170dca19e36 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 just mentioned how LISP 1 is a "phase 0 prototype effort", and > I suspect > the same is true, in some ways, of many of the lower numbered LISP > variants. > My sense is that the one that gets deployed in large-scale operational > service is likely to be LISP 4 or 5 (or more), i.e. one that's not yet > defined. But please note, that these are variants and not version numbers. That is, each number is using a particular method to do mapping. So LISP 1.x was suppose to convey routeable IDs, LISP 2 was suppose to convey a pull model and 2.0 is using DNS. And 3.0 is future stuff. So for instance (and this is not real yet and hasn't been written down), this is how I would number the variants: LISP 1 and 1.5: as documented in draft-00. LISP 2.x: uses a pull model where: LISP 2.0: uses DNS with port 53 LISP 2.1: uses DNS the protocol on a different port and infrastructure LISP 2.5: uses a new and different pull protocol LISP 3.x: uses a pull model that does not exist today, where: LISP 3.0: uses DHTs LISP 3.1: considers using Compact (or ROFL) Routing LISP 4.x: uses a push model that does not exist today, where: LISP 4.0: uses BGP not on port 179 LISP 4.1: uses Mark Handley's DNSpush style LISP 4.2: uses a push-n-pull model, where push happens at high levels and lower levels pull from the higher levels LISP >= 2 means: o Never routable IDs. o Could mean packets are dropped while waiting for lookups to complete. All variants of LISP assume: o The mapping function does not convey locator reachability status. o The EID-to-RLOC entries are relatively static, that is they change only at subscription time events. > My guess is that the architectural commonality between LISP 1/1.5/ > etc and the > eventual deployed stuff is likely to be: > > - Hosts and local routers don't need to be modified ISP routers that don't use LISP for TE won't have to be modified either. > - The existing internetwork layer is "jacked up" to become mostly an > end-end host naming layer > - End-end names are mapped into new locators as they cross the > boundary Right. > I think LISP is the first detailed proposal in the last half-decade > or so to > propose operating in this particular architectural quadrant (which > may well be > the only feasible one to operate in), and I suspect that's why it's > getting a > lot of attention. However, the final product may look quite > different from the > initial prototypes we have on paper now. Definitely. We are trying to draw a line in the sand to start off, but the line isn't really that deep. ;-) Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 16:01:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXO4-0000Tn-Db; Mon, 16 Apr 2007 16:01:20 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdXO2-0000TF-UF for ram@iab.org; Mon, 16 Apr 2007 16:01:18 -0400 Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdXO1-00039N-L8 for ram@iab.org; Mon, 16 Apr 2007 16:01:18 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by borg.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 16 Apr 2007 13:01:18 -0700 X-IronPort-AV: i="4.14,415,1170662400"; d="scan'208"; a="709386996:sNHT31848604" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3GK1HJ33745; Mon, 16 Apr 2007 13:01:17 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704162001.l3GK1HJ33745@merlot.juniper.net> To: jnc@mercury.lcs.mit.edu (Noel Chiappa) Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: Your message of "Mon, 16 Apr 2007 10:47:04 EDT." <20070416144704.4B9E1872F4@mercury.lcs.mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <57598.1176753676.1@juniper.net> Date: Mon, 16 Apr 2007 13:01:17 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Noel, > > From: Yakov Rekhter > > > My question was in the context of LISP 1.5. > > Dino just mentioned how LISP 1 is a "phase 0 prototype effort", and I suspect > the same is true, in some ways, of many of the lower numbered LISP variants. > My sense is that the one that gets deployed in large-scale operational > service is likely to be LISP 4 or 5 (or more), i.e. one that's not yet > defined. > > My guess is that the architectural commonality between LISP 1/1.5/etc and the > eventual deployed stuff is likely to be: > > - Hosts and local routers don't need to be modified > - The existing internetwork layer is "jacked up" to become mostly an > end-end host naming layer > - End-end names are mapped into new locators as they cross the boundary What you called "end-end names" are not really "end-end names" but locators. It just the scope of these locators is not the whole Internet. What you do at the boundaries is mapping of site-wide locators into the ISP locators. Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 22:26:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HddOF-0003ku-Ae; Mon, 16 Apr 2007 22:25:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HddOD-0003kp-HK for ram@iab.org; Mon, 16 Apr 2007 22:25:53 -0400 Received: from smtp02.uc3m.es ([163.117.136.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HddOA-0003nq-P1 for ram@iab.org; Mon, 16 Apr 2007 22:25:53 -0400 Received: from smtp02.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id AC695149520; Mon, 16 Apr 2007 19:38:23 +0200 (CEST) Received: from [163.117.203.88] (unknown [163.117.203.88]) by smtp02.uc3m.es (Postfix) with ESMTP id 9327713078E; Sun, 15 Apr 2007 00:41:32 +0200 (CEST) In-Reply-To: References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <649c58212946d793eed4ddc3367dedd2@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Sun, 15 Apr 2007 00:41:31 +0200 To: Dino Farinacci X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 1449ead51a2ff026dcb23465f5379250 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 El 13/04/2007, a las 6:27, Dino Farinacci escribi=F3: >>>> so are you envisioning an hybrid system that has both the push and=20= >>>> pull models? In such scheme there would be these mesh of high level=20= >>>> routers that exchange the whole loc id mapping database and then=20 >>>> smaller routers that use the pull model to query these high level=20= >>>> routers? >>> >>> Yes, I think something like that. >>> >>>> the new protocol would then run between these high level routers,=20= >>>> is that it? >>> >>> Yes, which will be trusted. As well as having a registration=20 >>> procedure that is pub/priv key protected for the ETRs to register=20 >>> EID-to-RLOC mappings. >>> >> >> So are you using a trust model that is based on a closed set of=20 >> participants that trust each other rather than a mean to certify that=20= >> the actual information about binding is correct? > > Yes. > but considering current BGP attacks, this model seems to have serious=20 limitations, especially, if you want to have a wider deployment, where=20= even smaller sites want to deploy an ID loc split solution.... >>> I think we have a good demarcation design where the LISP-00 ID can=20= >>> use various means to obtain the mappings. I can see any or all of=20 >>> the following: >>> >>> o Static >> >> i don't think we should preclude this one, but i don't think it is=20 >> general enough to solve our problems (i would leave it as a corner=20 >> case for testing and exceptions) > > May be adequate in TE-ITRs. agree > >>> o ICMP >> >> My take on this one is that much needs to change from its current=20 >> form to be secured. In particular you will need a few more message=20 >> exchange to achieve this. > > I realize that. That we can fix. Not worried about it too much. > >> Besides, you need a valid ID to locator mapping (with at least one=20 >> working locator) to actually send the initial request, so this needs=20= >> to be complemented with an additional mechanism. In LISP 1, the=20 >> mechanism is the identity, since the identifier is also a valid=20 >> locator. > > I don't understand your point here. > that if you move from LISP 1 the identifier is no longer routable as it=20= is and you need some additional infrastrcutre to solve the initila EID=20= to locator mapping in LISP 1.5 it seems that this is achieved through this alternative=20 routing infrastrucutre that is used to route packets containing=20 idnetifiers. Actually this is part of the EID to locator resolution=20 system in this case. For the other two flavoers of LISP, the EID is not routable per se, so=20= you will need to obtain the locators associated to a identifier=20 somehow, before starting the communication, so you cannot get them from=20= getting ICMP messages back as reply to the first packet (at least for=20 the initiator) You could get them from the DNS, along with the EID, when resolving the=20= fqdn, but this only works for hosts having fqdn and there are=20 additional situations when you need to solve the eid to locator mapping=20= when you don't have the possibility of using the fqdn as i mentioned in=20= another email recently >>> o DNS >> >> not sure what do you mean here... >> >> the DNS as used in HIP? i.e. using the DNS to obtain both the=20 >> identifier and the locator set associated to a fqdn >> or the DNS system to retrieve identifier to locator mapping, like for=20= >> instance using ULAs as identifiers and using the DNS reverse tree=20 >> entry for the ULA for retrieving the locators associated with this=20 >> identifier? > > The way we have been talking about it. Using DNS store mappings. > >> the DNS as a generic protocol independent of the current DNS system=20= >> to make a directory service for retrieving Id to locator mapping? > > Right. > >> In any case, in order to answer this question, i guess that an=20 >> important previous question is how do you think the identifier=20 >> namespace will be? I mean, it seems that DNS type of approach will=20 >> not scale to support an 128 bit unstrucutred identifier namespace.=20 >> OTOH, if you are thinking of using ULAs or PI addresses as=20 >> identifier, then this may work > > What will? 128-bits is a lot of addresses. Shouldn't even try. > not sure i understand what you mean here... let me ask a few clarifying questions: - what EIDs are you assuming? 128 bits long? 32 bits long? IPv4=20 addresses? unstructured 128 bits? IPv6 addresses? which ones? globally=20= routable v6 addresses? ULAs? other? - what do you think we shouldn't even try? using the DNS reverse tree=20 seems possible for doing EID to loc mapping whne the EID are ULAs or=20 globally routable addresses, since they are structured imho >>> o Push-only >>> o Push-n-pull >> >> i like your argument that it is good not to require every ITR to have=20= >> the full database, even in a push model. I think we should continue=20= >> exploring this solution space > > Okay, sounds good. > >>> o Pull with new database >>> >> >> again, i think this is closely related with the characteristics of=20 >> the identifier namespace. If we have an existnet protocol like the=20 >> DNS that can provide this feature, i don't see the need for this. > > How you pull and what you pull don't have to be related. I personally=20= > like prefixes where the size of the prefix is based on the number of=20= > systems you need assign IDs to. ok, at least, you are assuming that IDs will be aggrgegatable in the=20 sense that you can assign a block of them to an organization regards, marcelo= _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 16 23:49:55 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdehP-0003pM-82; Mon, 16 Apr 2007 23:49:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdehO-0003pH-84 for ram@iab.org; Mon, 16 Apr 2007 23:49:46 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdehK-0008GD-U7 for ram@iab.org; Mon, 16 Apr 2007 23:49:46 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id AFD6C59DEB; Tue, 17 Apr 2007 13:49:40 +1000 (EST) Message-ID: <462443C9.6010703@firstpr.com.au> Date: Tue, 17 Apr 2007 13:49:29 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] How does LISP recognise which IP addresses to query mapping for? References: <462059BB.10309@firstpr.com.au> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 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 Dino for your answers. Here is what I meant to say in my first question. In the case of IPv4, with LISP 2 or 3, which of these three (maybe all three, or some others) approaches would be used by the ITR to process each incoming packet? 1 - A single FIB which determines it is to be, for instance: a - Forwarded to interface 0. b - Forwarded to interface 1 etc. f - LISP encapsulated. That is, one set of rules which the destination address is tested against which implements the BGP FIB and the prefixes which the ITR knows about which are subject to LISP mapping. 2 - Firstly send the packet to FIB for BGP routes. If the packet fails to match that, then send it to a second set of rules which matches all the prefixes the ITR knows about which are LISP mapped. 3 - Alternatively, as 2, but try the LISP rules and then the BGP rules. (There could also be a set of rules which specify which addresses are known not to be LISP-mapped, but which are also currently, not in the BGP global routing table - to prevent the repeated generation of queries.) Since the LISP mapping rules could be quite numerous and subject to rapid change, there might be problems integrating them into a single FIB function with the BGP routes, if each update to that FIB involved lengthy computations and/or rewriting a lot of data. In all cases, if the packet matches neither set of rules, I guess there needs to be a set of prefixes which the ITR currently knows there are no LISP mappings for, and so not to generate a query to the central database about. (Alternatively, the set of LISP rules could specify, for some prefixes, that there was no LISP mapping.) Failing a match on all three of these sets of rules, I understand the packet should generate a query to the central database. Although the packet will probably be dropped, a subsequent packet to this address may find that a new rule as been added which causes it to be LISP encapsulated. RW>> I don't see how LISP 1.5 could be deployed incrementally, >> since the alternative routing system would need to be in >> place and LISP routers would need to be in practically >> every edge network, to ensure continued universal reachability >> of any addresses which were taken out of the BGP system and >> accessed as LISP EIDs instead. > It is done incrementally because if you route to a destination > site which is not LISP enabled, the ITR in the source site which > is LISP-enabled, will not learn a mapping so it will not > encapsulate the packet and send it natively like it does today. What I mean to ask is this: Lets say there is an attempt to introduce LISP 1.5 incrementally, on the basis of benefits as deployment increases, rather than purely because we all need to do it by year X or the sky will fall in. In this scenario, I think the reasons an edge network would install LISP routers inside its network and/or at its border(s) would be: 1 - It wanted to have some of its internal IP addresses LISP-mapped and so taken out of the BGP system. or 2 - It didn't want to LISP map any of its IP addresses, but it wanted to support local users communicating with LISP-mapped IP addresses in other edge networks. I foresee a chicken and egg situation. Why would some low-key, cost-constrained, just scraping by, edge network install and properly configure one or more LISP routers unless a significant proportion of its users complained that sites, mailservers etc. they want to access have become inaccessible? At the other end, in a second edge network which was favourably disposed to LISP, why would they take some of their addresses out of the BGP system and make them available only via LISP, when they know that 90%, 20% or even 0.1% of remote users are in networks which don't provide an ITR which would enable them to access those IP addresses? RW>> I think LISP 2 or 3 could have significant benefits, but I >> think they too would require a complete upgrade, since no-one >> would want > What do you mean by complete? I mean a long-term plan, made in 2007 and broadly agreed to in 2008 as being the only viable long-term option for the development of the Internet's architecture, which ideally involves replacing things which are going to be replaced anyway (I am thinking border and transit routers, or at least multihomed border routers and transit routers), with new things which conform to a specification which implements the new architecture. Then, the impetus is "when replacing, make sure the new gear will be what we want after 2012". All this gear will be replaced in that timeframe anyway. The incremental cost of the new features would probably be minimal - and far less than keeping on flogging the old architecture with more and more expensive conventional router technology. The impetus is not that doing something today will bring benefits today or next month - just that we can transition to a new set of equipment and (I suggest) new arrangements for address management, arriving at a complete changeover without actually forcibly ripping out gear which wouldn't have been replaced anyway. I am currently thinking of an SRAM-based upgrade to border and transit routers with something like LISP in the border routers, with an option for pushing LISP functions back into the edge network if they are too burdensome for the busier edge routers. >> to make their IP addresses inaccessible to the fraction of >> edge networks which had not installed LISP routers. (Unless >> there is a way of catching the packets in the DFZ, with special >> LISP routers - but then someone would need to pay for that, >> when it should be the responsibility of each edge network to >> pay for its own LISP capabilities.) > In the transition case, where a new site still needs to put their > routes in the BGP-core, the site still gets ingress traffic > engineering. So it's not just one problem we are focusing on. I understand that mapping some IP addresses to LISP provides TE options and multihoming management down to the granularity of a single IP address - but the addresses are only accessible by users of edge networks who have installed LISP routers. I could imagine a LISP 1.5+ upgrade over the replacement cycle, with the benefits becoming practical only once all edge networks had upgraded. But I can't imagine many edge networks wanting to switch addresses to LISP-accessibility, until essentially all other edge networks had fully deployed LISP routers. >> Here is why I think the central database needs to be able to >> tell the ITR a definite "No" if the requested IP address is not >> mapped by the LISP system, and to tell the ITR the prefix which >> this address is part of, for which the same answer applies. (I >> assume that a response returning mapping would also indicate >> the enclosing prefix, as with the 5 bit EID Mask length and 32 >> bit EID prefix in the draft-farinacci-lisp-00.) > Sure, this can be done. OK. >> I also think there needs to be a TTL or similar - to tell the >> ITR how long to cache this information for. (I don't see a TTL >> in the ICMP "Control-Plane Packet Format in >> draft-farinacci-lisp-00 - but it strikes me that one would be >> desirable.) > Yes, we will add this in the next draft. With a query/reply > protocol, we need a TTL. With a push protocol, we may not need > one. I agree. BTW, the ICMP packet diagram doesn't have realistic bit lengths for the EID Mask Length, EID Prefix or Routing Locator. >> It sends a request to the database. If the only way the >> database can answer "No" is to not respond, then the ITR has to >> record that this particular IP address has no LISP mapping, so >> the packet should be dropped. However, the ITR also needs to >> remember this for that IP address, for some configurable time, >> to prevent it repeating the query when another packet arrives >> for this address. The amount of state to be stored could get >> out of hand if it was repeated on a large number of IP >> addresses, as would happen with a user scanning a large number >> of IP addresses for some reason. > It has been suggested, to avoid these class or problems, is to > have the ISP deploy a proxy LISP ETR on behalf a sites that do not > have LISP enabled. I don't understand this. If the ISP runs the edge network, users of that ISP need to access an ETR so they can access LISP-mapped IP addresses. I understand that this has to be achieved by one or more ETRs inside the edge network, or by the border routers functioning as ETRs. I don't know how an ETR could be deployed amongst transit routers to save an ISP from having to deploy a LISP router, unless perhaps there was some trick in BGP to route all LISP-mapped addresses to this "in-the-core" LISP router. Maybe we are trying to answer different questions - this is a pretty wide-ranging discussion! - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 05:22:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjs8-00021a-MR; Tue, 17 Apr 2007 05:21:12 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdjs6-00021N-DZ for ram@iab.org; Tue, 17 Apr 2007 05:21:10 -0400 Received: from smtp01.uc3m.es ([163.117.136.121]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdjs4-0008BK-QX for ram@iab.org; Tue, 17 Apr 2007 05:21:10 -0400 Received: from smtp01.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 186B217BD1D; Tue, 17 Apr 2007 11:15:15 +0200 (CEST) Received: from [163.117.139.32] (chelo-it-uc3m-es.it.uc3m.es [163.117.139.32]) by smtp01.uc3m.es (Postfix) with ESMTP id DDBA817BE7D; Tue, 17 Apr 2007 11:07:53 +0200 (CEST) In-Reply-To: <200704162001.l3GK1HJ33745@merlot.juniper.net> References: <200704162001.l3GK1HJ33745@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v624) Content-Type: text/plain; charset=ISO-8859-1; format=flowed Message-Id: <64b26c72c5903c231794106ca5be3f63@it.uc3m.es> Content-Transfer-Encoding: quoted-printable From: marcelo bagnulo braun Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Tue, 17 Apr 2007 11:07:57 +0200 To: Yakov Rekhter X-Mailer: Apple Mail (2.624) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: Noel Chiappa , 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 Yakov, El 16/04/2007, a las 22:01, Yakov Rekhter escribi=F3: > Noel, > >>> From: Yakov Rekhter >> >>> My question was in the context of LISP 1.5. >> >> Dino just mentioned how LISP 1 is a "phase 0 prototype effort", and I=20= >> suspect >> the same is true, in some ways, of many of the lower numbered LISP=20 >> variants. >> My sense is that the one that gets deployed in large-scale = operational >> service is likely to be LISP 4 or 5 (or more), i.e. one that's not = yet >> defined. >> >> My guess is that the architectural commonality between LISP 1/1.5/etc=20= >> and the >> eventual deployed stuff is likely to be: >> >> - Hosts and local routers don't need to be modified >> - The existing internetwork layer is "jacked up" to become mostly an >> end-end host naming layer >> - End-end names are mapped into new locators as they cross the=20 >> boundary > > What you called "end-end names" are not really "end-end names" but > locators. but they can be end to end names, since they can be globally unique.=20 OTOH, they cannot be globally routable. So, they can be global identifiers as Noel mentions, but also as you=20 mention they are locators with a narrower scope (the site). this is=20 what basically ULAs are regards, marcelo > It just the scope of these locators is not the whole > Internet. What you do at the boundaries is mapping of site-wide > locators into the ISP locators. > > Yakov. > > _______________________________________________ > 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 Apr 17 06:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdkx8-0007Wp-3J; Tue, 17 Apr 2007 06:30:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdkx7-0007Wk-Bm for ram@iab.org; Tue, 17 Apr 2007 06:30:25 -0400 Received: from smtp-2.dynsipr.ucl.ac.be ([130.104.4.2] helo=smtp2.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdkx4-0006Wn-U5 for ram@iab.org; Tue, 17 Apr 2007 06:30:25 -0400 Received: from smtp2.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP id 41757DB50B; Tue, 17 Apr 2007 12:30:19 +0200 (CEST) Received: from [10.1.254.35] (open-net.ee.surrey.ac.uk [131.227.76.238]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTP; Tue, 17 Apr 2007 12:30:17 +0200 (CEST) Message-ID: <4624D9FF.1080309@info.ucl.ac.be> Date: Tue, 17 Apr 2007 16:30:23 +0200 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: Yakov Rekhter Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <200704151259.l3FCxJJ63686@merlot.juniper.net> In-Reply-To: <200704151259.l3FCxJJ63686@merlot.juniper.net> 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=-20.539, requis 5, autolearn=not spam, BAYES_00 -2.60, DATE_IN_FUTURE_03_06 1.96, RCVD_AUTH_OK -20.00, SARE_FROM_SPAM_WORD3 0.10, SPF_HELO_PASS -0.00) X-SGSI-From: bonaventure@info.ucl.ac.be X-SGSI-Spam-Status: No X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Cc: Tony Li , ram@iab.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 Yakov, >>If I can paraphrase you, Ross, doing packet forwarding at 10Mpps >>doesn't scare me. > > > How many EID-to-RLOC mappings ICMP messages per second an ITR/ETR be > required to originate/receive ? We did a related study several years ago based on Netflow traces collected in 1999. We used Netflow traces from two different ISPs, one was a dialup ISP (about 6 Mbps of peak traffic) and the other a research ISP (about 80 Mbps of peak traffic). At that time, the BGP tables in the DFZ contained 70000 prefixes and we used the trace to look at the number of tunnels that would have to be established towards the prefixes that are actually receiving packets from the studied ISPs. For the dialup ISP, there were about 2000 tunnels active (assuming that a tunnel was active during every minute in which a packet was sent towards the prefix) on average. For the research ISP, there were about 12000 active tunnels. The average churn for the tunnels was of about 10%. If we had tested a solution like LISP at that time, the dialup ISP would have received on average 200 ICMP messages per minute (with peaks of 900). For the research ISP, the average was 1100 ICMP messages per minute and the peak about 1500 ICMP per minute. Additional information about the traffic traces and the results may be found in the (old) paper below [UB00] S. Uhlig and O. Bonaventure. On the cost of using MPLS for interdomain traffic. In Quality of Future Internet Services (QoFIS 2000), September 2000. Available from http://totem.info.ucl.ac.be/publications.html We expect that the Internet traffic has changed a lot since 1999 with the introduction of peer-to-peer and worms. These two factors probably increase the number tunnels that need to be established and maintained. 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 Apr 17 10:00:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoEd-0002Us-FJ; Tue, 17 Apr 2007 10:00:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoEZ-0002Ua-NR for ram@iab.org; Tue, 17 Apr 2007 10:00:39 -0400 Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdoEW-0005qU-N2 for ram@iab.org; Tue, 17 Apr 2007 10:00:39 -0400 Received: from unknown (HELO merlot.juniper.net) ([172.17.27.10]) by kremlin.juniper.net with ESMTP/TLS/DES-CBC3-SHA; 17 Apr 2007 07:00:36 -0700 X-IronPort-AV: i="4.14,419,1170662400"; d="scan'208"; a="688357533:sNHT29443236" Received: from juniper.net (sapphire.juniper.net [172.17.28.108]) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id l3HE0VJ40487; Tue, 17 Apr 2007 07:00:31 -0700 (PDT) (envelope-from yakov@juniper.net) Message-Id: <200704171400.l3HE0VJ40487@merlot.juniper.net> To: Dino Farinacci Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) In-Reply-To: Your message of "Mon, 16 Apr 2007 10:01:43 PDT." <773A9F70-2BC6-4B4D-9ABE-A154776C695C@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <21300.1176818431.1@juniper.net> Date: Tue, 17 Apr 2007 07:00:31 -0700 From: Yakov Rekhter X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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, > All variants of LISP assume: > > o The mapping function does not convey locator reachability status. > > o The EID-to-RLOC entries are relatively static, that is they change > only at subscription time events. > > > My guess is that the architectural commonality between LISP 1/1.5/ > > etc and the eventual deployed stuff is likely to be: > > > > - Hosts and local routers don't need to be modified > > ISP routers that don't use LISP for TE won't have to be modified either. If an ISP does not use LISP for TE, then according to the above none of the ISP's routers have to be modified, which means that such an ISP does not need to deploy any ITRs/ETRs. And if neither hosts nor local routers have to be modified, then none of the local routers need to be ITRs/ETRs. So, where would the ITRs/ETRs be deployed ? Yakov. _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 10:13:09 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoQd-0000Cu-VX; Tue, 17 Apr 2007 10:13:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdoQb-0000C2-DC for ram@iab.org; Tue, 17 Apr 2007 10:13:06 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdoQa-00012t-6t for ram@iab.org; Tue, 17 Apr 2007 10:13:05 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 0728986AE8; Tue, 17 Apr 2007 10:13:01 -0400 (EDT) To: ram@iab.org Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Message-Id: <20070417141301.0728986AE8@mercury.lcs.mit.edu> Date: Tue, 17 Apr 2007 10:13:01 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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: Yakov Rekhter >> My guess is that the architectural commonality between LISP >> 1/1.5/etc and the eventual deployed stuff is likely to be: >> .. >> - End-end names are mapped into new locators as they cross the >> boundary > What you called "end-end names" are not really "end-end names" but > locators. In the current "classic" IPvN architecture, yes, the end-end names are also locators. In LISP: > It just the scope of these locators is not the whole Internet. The end-end names in LISP are also locators with local scope, it is true. However, they are *principally* end-end names. And as I said a while back (to Ran Atkinson, if memory serves), over time, it's possible that the LISP mapping function would move closer and close to the hosts, which would mean that the scope of those locally-significant locators would get smaller and smaller. The limit of this process is clear: is a "locator" with zero scope really a locator? All the while, their end-end naming function would remain unchanged, which is why I think of them as *principally* end-end names. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 10:24:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdobJ-0004ic-B5; Tue, 17 Apr 2007 10:24:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdobH-0004dp-QL for ram@iab.org; Tue, 17 Apr 2007 10:24:07 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdobG-0003Xz-GV for ram@iab.org; Tue, 17 Apr 2007 10:24:07 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2007 16:24:07 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HEO5uY019717; Tue, 17 Apr 2007 16:24:05 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp332.cisco.com [10.61.65.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HEO5lZ024016; Tue, 17 Apr 2007 14:24:05 GMT Message-ID: <4624D883.8080708@cisco.com> Date: Tue, 17 Apr 2007 16:24:03 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <200704171400.l3HE0VJ40487@merlot.juniper.net> In-Reply-To: <200704171400.l3HE0VJ40487@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1204; t=1176819845; x=1177683845; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=Rh1N978gPh2wmtT5dtpDejdgy3It3iGQGmrPrJATdzI=; b=IWEGCudS22f+Y6YxTqD3EbR0SxHduHlv6+FonN8xDMGly2QWs+dwjInjN5W+V1Q1ABJqYg0Z kkGhXxVmuOvNw3XyC8U9de7AJknaNfbjy2ktv8VCgx5qHxrA2WT5qPLz; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Yakov Rekhter wrote: > If an ISP does not use LISP for TE, then according to the above > none of the ISP's routers have to be modified, which means that such > an ISP does not need to deploy any ITRs/ETRs. And if neither hosts nor > local routers have to be modified, then none of the local routers > need to be ITRs/ETRs. So, where would the ITRs/ETRs be deployed ? > Let's distinguish ITRs and ETRs. ETRs are only needed by those who advertise (through whatever means) LISP-based address space. ITRs MUST be deployed by either ISPs. their "upstreams" (for some value of "upstream") or their customers in order to route to PI LISP participants whose routes have been withdrawn. Any one of those three models might suit a given situation. Take for instance a multihomed customer with full BGP routing, who is already running an ETR. Perhaps it makes sense for that customer to take on the ITR functionality as well, so that they can optimize routing. OTOH, a large ISP may want to deploy ITRs either at the PE or some place nearby for their customers. Or, a small ISP might make use of an upstream ITR. There are probably other games available, as well. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 11:15:13 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpOY-0002rj-Ae; Tue, 17 Apr 2007 11:15:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpOX-0002rc-3a for ram@iab.org; Tue, 17 Apr 2007 11:15:01 -0400 Received: from mtagate1.uk.ibm.com ([195.212.29.134]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpOU-000880-Mc for ram@iab.org; Tue, 17 Apr 2007 11:15:01 -0400 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate1.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l3HFEwoY040316 for ; Tue, 17 Apr 2007 15:14:58 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.3) with ESMTP id l3HFEv5R2810028 for ; Tue, 17 Apr 2007 16:14:57 +0100 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 l3HFEvHK027517 for ; Tue, 17 Apr 2007 16:14:57 +0100 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 l3HFEv0h027497; Tue, 17 Apr 2007 16:14:57 +0100 Received: from [9.4.210.149] ([9.4.210.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id RAA334488; Tue, 17 Apr 2007 17:14:53 +0200 Message-ID: <4624E471.8090106@zurich.ibm.com> Date: Tue, 17 Apr 2007 17:14:57 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Noel Chiappa Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <20070417141301.0728986AE8@mercury.lcs.mit.edu> In-Reply-To: <20070417141301.0728986AE8@mercury.lcs.mit.edu> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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 > All the while, their end-end naming function would remain unchanged, which > is why I think of them as *principally* end-end names. That's valid from a 10,000 meter Internet architect viewpoint. I suspect that from the viewpoint of a repair technician at or slightly below ground level, they would remain *principally* IP addresses, as today. That's actually the beauty of LISP. Brian _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 11:30:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpdW-0003Yv-L5; Tue, 17 Apr 2007 11:30:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdpdV-0003Yh-8u for ram@iab.org; Tue, 17 Apr 2007 11:30:29 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdpdR-0004Ln-CM for ram@iab.org; Tue, 17 Apr 2007 11:30:29 -0400 Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2007 17:30:24 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l3HFUO2C009995; Tue, 17 Apr 2007 17:30:24 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp332.cisco.com [10.61.65.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HFUDlZ017757; Tue, 17 Apr 2007 15:30:13 GMT Message-ID: <4624E803.60402@cisco.com> Date: Tue, 17 Apr 2007 17:30:11 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: Yakov Rekhter Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <200704162001.l3GK1HJ33745@merlot.juniper.net> In-Reply-To: <200704162001.l3GK1HJ33745@merlot.juniper.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1582; t=1176823824; x=1177687824; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=6uWFWOC9x/bjI5PmAQvfAViB++fTtzz+Q7qky1Q82Qg=; b=apN+MsCuKV0gGRwJ62yLQufABbpjcBQW37EmCwoc3rlSg6qRKgUczCWXw/q90lgr5w22oe0W sezwvdnbfGhX+wuptqSus243s8+p2PSQOwrsOHuUKeOyDTl29MVIjrfE; Authentication-Results: ams-dkim-1; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim1002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Cc: Noel Chiappa , 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 Yakov, > What you called "end-end names" are not really "end-end names" but > locators. It just the scope of these locators is not the whole > Internet. What you do at the boundaries is mapping of site-wide > locators into the ISP locators. > I think this is a great way to look at the engineering problems we are targeting. Scope in the case of LISP indicates the appropriate lookup mechanism. How that scope is determined is something of an open question. For instance, one could say that an address falls within the global routing scope if an entry for it exists within the RIB. One could say that an address falls within the global LISP scope (for lack of better words) if an EID/RLOC mapping can somehow be determined. The benefit of such an approach is that it keeps us out of all the pitfalls that application developers have warned us for years. We retain transparency, retain the same APIs, and we provide for a transition. Here is the real question: how responsive can the network be in the face of a failure, and what is the restoration time from that failure? Therein lies the rub. By the way, I still believe we should invest more research efforts in HIP, and API issues relating to a LOC/ID split that occurs on the host. A lot of the standardization would not normally happen under the auspices of the IETF, but rather in the IEEE under POSIX. It'd be sort of funny if we made this their problem ;-) And then funnier when a bunch of the same faces showed up there, making it our problem again :-) Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 11:47:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdptd-0001gZ-Tx; Tue, 17 Apr 2007 11:47:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdptc-0001fZ-5e for ram@iab.org; Tue, 17 Apr 2007 11:47:08 -0400 Received: from slb-smtpout-01.boeing.com ([130.76.64.48] helo=slb-smtpout-01.ns.cs.boeing.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HdptY-0003pq-2j for ram@iab.org; Tue, 17 Apr 2007 11:47:06 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by slb-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3HFl3gV029920 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 08:47:03 -0700 (PDT) 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 l3HFl27H022890; Tue, 17 Apr 2007 08:47:02 -0700 (PDT) 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 l3HFkrCL022607; Tue, 17 Apr 2007 08:47:02 -0700 (PDT) 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); Tue, 17 Apr 2007 08:47:02 -0700 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] 6to4 Date: Tue, 17 Apr 2007 08:46:48 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED705@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <7BD4CF97-E5C7-46F3-8091-19AA750BE3A4@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] 6to4 Thread-Index: AceARDgvpp7JAC4USg+mK23Ta+IVwAAwjlLA References: Your message of "Fri, 13 Apr 2007 10:44:22 PDT." <200704161236.l3GCaFJ34923@merlot.juniper.net> <39C363776A4E8C4A94691D2BD9D1C9A1029ED6FB@XCH-NW-7V2.nw.nos.boeing.com> <7BD4CF97-E5C7-46F3-8091-19AA750BE3A4@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" X-OriginalArrivalTime: 17 Apr 2007 15:47:02.0163 (UTC) FILETIME=[A41F7E30:01C78107] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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'm not sure on all your points, so let's walk through this:=20 > > I am wondering where 6to4 fits on the LISP continuum. >=20 > Well, it can work serially. Here is the scenario I am referring to: >=20 > o An IPv6 packet is received by an ITR. OK; either that, or the ITR resolves a FQDN and gets back a 6to4 address. > o The DA is an EID so a mapping lookup is done to yield a locator in =20 > the 2002::/16 > range. OK. > o The ITR prepends a IPv6 header. Huh? 6to4 prepends IPv4 headers; not IPv6. > o The platform specific code in the router will try to=20 > resolve a next-=20 > hop and find > out there is no IPv6 next-hop for the outer DA. So it=20 > resolves the =20 > address to > an IPv4 address which follows the 2002 bits. The ITR prepends an =20 > IPv4 header. So, now you have IPv6-in-IPv6-in-IPv4? 6to4 is only for IPv6-in-IPv4. > o The ITR sends the packet out the interface where the IPv4 DA is =20 > resolved to. I don't know what you mean by this; my understanding is that the ITR would simply launch the IPv6-in-IPv4 packet into the network and let IPv4 routing steer it to the correct ETR.=20 > > Correct me if I am wrong, but with 6to4 the identifer > > to locator mapping comes from a single DNS lookup. The > > identifer is not routeable over the core, but the ETR > > locator is embedded in the identifier address so the > > ETR discovery comes "for free". >=20 > The EID in DNS could be a 2002::/16 prefix, but it shouldn't assume =20 > the address > itself or the IPv4 embedded in it is routable. Not the way 6to4 works; in 6to4, the embedded IPv4 address is indeed routable. > > Is 6to4 an example of LISP 2? Is it good enough to be >=20 > Well you can put 2002 addresses in DNS. So from a LISP point=20 > of view, =20 > it just a > mapping lookup on a string of bits. >=20 > > considered as a long-term solution, or is it just a > > baby-step to a fully jacked-up LISP deployment? >=20 > If you used IPv6 addresses as EIDs and IPv4 addresses as locators, =20 > then the 6to4 step would be an extra one you would not need. And I =20 > wouldn't want to use it because it adds an additional 20=20 > bytes to the =20 > packet (as described from the sequence above). AFAICT, there is no difference between LISP and 6to4 in this regard. LISP encapsulates IPvX-in-IPvY, but for 6to4 it just so happens that X=3D6 and Y=3D4. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 12:04:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdq9y-0002Ms-Dh; Tue, 17 Apr 2007 12:04:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdq9x-0002Mn-Jy for ram@iab.org; Tue, 17 Apr 2007 12:04:01 -0400 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 1Hdq9w-0001ZG-HW for ram@iab.org; Tue, 17 Apr 2007 12:04:01 -0400 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JGNGMK01.F2R; Tue, 17 Apr 2007 18:03:56 +0200 In-Reply-To: <4624E803.60402@cisco.com> X-Priority: 1 (High) To: Eliot Lear Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Tue, 17 Apr 2007 18:02:27 +0200 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 17/04/2007 18:03:55, Serialize complete at 17/04/2007 18:03:55 X-Spam-Score: 0.4 (/) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 Cc: Noel Chiappa , 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="===============1373260839==" Errors-To: ram-bounces@iab.org This is a multipart message in MIME format. --===============1373260839== Content-Type: multipart/alternative; boundary="=_alternative 00581DBEC12572C0_=" This is a multipart message in MIME format. --=_alternative 00581DBEC12572C0_= Content-Type: text/plain; charset="US-ASCII" Eliot, Eliot Lear wrote on 17/04/2007 17:30:11: > Yakov, > > What you called "end-end names" are not really "end-end names" but > > locators. It just the scope of these locators is not the whole > > Internet. What you do at the boundaries is mapping of site-wide > > locators into the ISP locators. > > > > I think this is a great way to look at the engineering problems we are > targeting. Scope in the case of LISP indicates the appropriate lookup > mechanism. How that scope is determined is something of an open > question. For instance, one could say that an address falls within the > global routing scope if an entry for it exists within the RIB. One > could say that an address falls within the global LISP scope (for lack > of better words) if an EID/RLOC mapping can somehow be determined. I think this is not very different from what I proposed in the draft on TIDR, where there are a couple of tables: the RIB for "locator prefixes", and the TIB (i.e. the Tunnel Information Base) for the "identifier prefixes". It is outside the interdomain infrastructure when "identifier prefixes" become "locator prefixes". And it is the presence of the LOCATOR attribute what permits to say whether a prefix is a "locator prefix" or an "identifier prefix". When I first wrote the draft on TIDR I had a couple of choices: either to use the LOCATOR attribute to assign locators to identifiers, or to use the IDENTIFIERS attribute to specify which identifiers can be reached through the locator specified in the BGP update. In my draft I selected the first choice because I thought the LOCATOR attribute provided a smoother deployment. But I have been thinking more on this topic and now I think that a new IDENTIFIERS attribute would give additional benefits with regard to the BGP update processing. I will try to send a note tomorrow explaining this, to see if the BGP-based push method that I proposed in the TIDR draft could be useful. Regards, Juanjo --=_alternative 00581DBEC12572C0_= Content-Type: text/html; charset="US-ASCII"
Eliot,

Eliot Lear <lear@cisco.com> wrote on 17/04/2007 17:30:11:

> Yakov,
> > What you called "end-end names" are not really "end-end names" but
> > locators. It just the scope of these locators is not the whole
> > Internet. What you do at the boundaries is mapping of site-wide
> > locators into the ISP locators.
> >  
>
> I think this is a great way to look at the engineering problems we are
> targeting.  Scope in the case of LISP indicates the appropriate lookup
> mechanism.  How that scope is determined is something of an open
> question.  For instance, one could say that an address falls within the
> global routing scope if an entry for it exists within the RIB.  One
> could say that an address falls within the global LISP scope (for lack
> of better words) if an EID/RLOC mapping can somehow be determined.
I think this is not very different from what I proposed in the
draft on TIDR, where there are a couple of tables: the RIB for
"locator prefixes", and the TIB (i.e. the Tunnel Information Base)
for the "identifier prefixes". It is outside the interdomain
infrastructure when "identifier prefixes" become "locator prefixes".

And it is the presence of the LOCATOR attribute what permits to
say whether a prefix is a "locator prefix" or an "identifier prefix".

When I first wrote the draft on TIDR I had a couple of choices:
either to use the LOCATOR attribute to assign locators to
identifiers, or to use the IDENTIFIERS attribute to specify
which identifiers can be reached through the locator specified
in the BGP update.

In my draft I selected the first choice because I thought
the LOCATOR attribute provided a smoother deployment. But
I have been thinking more on this topic and now I think
that a new IDENTIFIERS attribute would give additional
benefits with regard to the BGP update processing.

I will try to send a note tomorrow explaining this, to see
if the BGP-based push method that I proposed in the TIDR
draft could be useful.

Regards,
Juanjo
--=_alternative 00581DBEC12572C0_=-- --===============1373260839== 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 --===============1373260839==-- From ram-bounces@iab.org Tue Apr 17 12:36:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqfV-0003Mn-LP; Tue, 17 Apr 2007 12:36:37 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqfV-0003Mh-76 for ram@iab.org; Tue, 17 Apr 2007 12:36:37 -0400 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 1HdqfQ-00043S-Hm for ram@iab.org; Tue, 17 Apr 2007 12:36:37 -0400 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 l3HGaN1N007378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 11:36:24 -0500 (CDT) 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 l3HGaM3o016366; Tue, 17 Apr 2007 09:36:23 -0700 (PDT) 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 l3HGaG14016058; Tue, 17 Apr 2007 09:36:22 -0700 (PDT) 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); Tue, 17 Apr 2007 09:36:20 -0700 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Tue, 17 Apr 2007 09:35:51 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED706@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <20070417141301.0728986AE8@mercury.lcs.mit.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Thread-Index: AceA+onnF/nayDq0Qz24LEjz4+wawgAE7hBg References: <20070417141301.0728986AE8@mercury.lcs.mit.edu> From: "Templin, Fred L" To: "Noel Chiappa" , X-OriginalArrivalTime: 17 Apr 2007 16:36:20.0262 (UTC) FILETIME=[87499460:01C7810E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de 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 > And as I said a while back (to Ran Atkinson, if memory serves), over time, > it's possible that the LISP mapping function would move closer and close to > the hosts, I have been saying this all along; once even to you, IIRC. Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 12:53:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqwI-00028u-Sq; Tue, 17 Apr 2007 12:53:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HdqwH-00026i-Lq for ram@iab.org; Tue, 17 Apr 2007 12:53:57 -0400 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 1HdqwG-0002ZW-D8 for ram@iab.org; Tue, 17 Apr 2007 12:53:57 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3HGroI0008209 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 09:53:51 -0700 (PDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3HGrogO001622; Tue, 17 Apr 2007 11:53:50 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3HGrlxJ001521; Tue, 17 Apr 2007 11:53:50 -0500 (CDT) 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); Tue, 17 Apr 2007 09:53:46 -0700 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Tue, 17 Apr 2007 09:53:36 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED707@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <773A9F70-2BC6-4B4D-9ABE-A154776C695C@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Thread-Index: AceAShVwclgPyPINRzuDA3JNSAD8mwAxonEA References: <20070416144704.4B9E1872F4@mercury.lcs.mit.edu> <773A9F70-2BC6-4B4D-9ABE-A154776C695C@cisco.com> From: "Templin, Fred L" To: "Dino Farinacci" , "Noel Chiappa" X-OriginalArrivalTime: 17 Apr 2007 16:53:47.0103 (UTC) FILETIME=[F740D6F0:01C78110] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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, > LISP 2.x: uses a pull model where: > LISP 2.0: uses DNS with port 53 OK - that would be *the* DNS. > LISP 2.1: uses DNS the protocol on a different port and =20 > infrastructure Could be a site-specific name resolution service that looks like DNS, e.g., LLMNR. > LISP 2.5: uses a new and different pull protocol What about a combination of 2.0 and 2.1, i.e., you look up the locator in *the* DNS and you look up the identifier in a site-specific name resolution service? Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 12:54:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqx3-0002rV-Ha; Tue, 17 Apr 2007 12:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdqx2-0002rJ-5x for ram@iab.org; Tue, 17 Apr 2007 12:54:44 -0400 Received: from ams-iport-1.cisco.com ([144.254.224.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hdqx0-0002zn-I1 for ram@iab.org; Tue, 17 Apr 2007 12:54:44 -0400 Received: from ams-dkim-2.cisco.com ([144.254.224.139]) by ams-iport-1.cisco.com with ESMTP; 17 Apr 2007 18:54:37 +0200 Received: from ams-core-1.cisco.com (ams-core-1.cisco.com [144.254.224.150]) by ams-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l3HGsaWx022150; Tue, 17 Apr 2007 18:54:36 +0200 Received: from [212.254.247.6] (ams3-vpn-dhcp332.cisco.com [10.61.65.76]) by ams-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id l3HGsRlZ012143; Tue, 17 Apr 2007 16:54:28 GMT Message-ID: <4624FBC2.7020200@cisco.com> Date: Tue, 17 Apr 2007 18:54:26 +0200 From: Eliot Lear User-Agent: Thunderbird 2.0a1 (Macintosh/20060724) MIME-Version: 1.0 To: "Templin, Fred L" Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) References: <20070417141301.0728986AE8@mercury.lcs.mit.edu> <39C363776A4E8C4A94691D2BD9D1C9A1029ED706@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <39C363776A4E8C4A94691D2BD9D1C9A1029ED706@XCH-NW-7V2.nw.nos.boeing.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1702; t=1176828876; x=1177692876; c=relaxed/simple; s=amsdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=lear@cisco.com; z=From:=20Eliot=20Lear=20 |Subject:=20Re=3A=20[RAM]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP) |Sender:=20; bh=iqY/8f0OUPFMcwrA+0jGLxyn9VHr+Wr48KoqX9yXCyk=; b=AcTLrnShZPoZWEYgXsqI31aTiTUz4S2plq9Bn9cPh9sqV8O1t6wWFd0Dgr1mDXaa6meFkJa7 27HodpBhn7x2/FwKAkdR4uuXwj3RMTP50tq0C6b75y9mKxM/PJLQkLsz; Authentication-Results: ams-dkim-2; header.From=lear@cisco.com; dkim=pass (s ig from cisco.com/amsdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: Noel Chiappa , 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 Fred, > >> it's possible that the LISP mapping function would move closer and >> >> close to the hosts, >> > > I have been saying this all along; once even to you, IIRC. > It depends on what you mean, but in general I would view this as a bad thing. Let's again discuss ETRs and ITRs separately. If you wish to move the ETR function closer to the host then you must either advertise a more specific EID/prefix match, in which case you will explode the number of mappings (still not a good thing), or you will impose suboptimal routing if multiple interior ETRs advertise the same EID/prefix. In the general case, there are only so many ways into and out of an end site, and so it's not clear what benefit you buy by moving these things toward the host, other than perhaps distributing the untunneling load, assuming the cost of doing so is huge to begin with (I do not believe it is). ITRs are also best kept to a minimum, but it is less demanding on everyone else because we don't have to know about where you put your ITRs (although you still impose load in terms of determining the mapping). Still, each ITR is going to need to play the mapping game. This means that either there is a predistributed and precomputed TIB, to borrow terminology from Juanjo, or you must reconstruct the entries realtime (or a mixture of both). I think you want to do as little of that as possible, no matter which way you slice it. It is true it would reduce your memory requirements on single devices, but it also adds complexity into your IGP which for most end sites is not there today. The mapping function is again key here. Eliot _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Tue Apr 17 14:39:54 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsag-0007tL-0N; Tue, 17 Apr 2007 14:39:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hdsae-0007tD-Na for ram@iab.org; Tue, 17 Apr 2007 14:39:44 -0400 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 1Hdsad-0002gw-Bu for ram@iab.org; Tue, 17 Apr 2007 14:39:44 -0400 Received: from slb-av-01.boeing.com (slb-av-01.boeing.com [129.172.13.4]) by blv-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3HIdVat025172 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 17 Apr 2007 11:39:32 -0700 (PDT) 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 l3HIdVx0026179; Tue, 17 Apr 2007 11:39:31 -0700 (PDT) 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 l3HIdSbx026075; Tue, 17 Apr 2007 11:39:31 -0700 (PDT) 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); Tue, 17 Apr 2007 11:39:28 -0700 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] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Tue, 17 Apr 2007 11:39:27 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED70A@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: <4624FBC2.7020200@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Thread-Index: AceBERitAwVbAsFTRyqTwmpMdMDSXQADSMGw References: <20070417141301.0728986AE8@mercury.lcs.mit.edu> <39C363776A4E8C4A94691D2BD9D1C9A1029ED706@XCH-NW-7V2.nw.nos.boeing.com> <4624FBC2.7020200@cisco.com> From: "Templin, Fred L" To: "Eliot Lear" X-OriginalArrivalTime: 17 Apr 2007 18:39:28.0544 (UTC) FILETIME=[BB0BF200:01C7811F] X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Cc: Noel Chiappa , 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 possible that the LISP mapping function would move closer and > >> =20 > >> close to the hosts, > >> =20 > > > > I have been saying this all along; once even to you, IIRC. > > =20 >=20 > It depends on what you mean, but in general I would view this=20 > as a bad=20 > thing. Let's again discuss ETRs and ITRs separately. If you wish to=20 > move the ETR function closer to the host then you must either=20 > advertise=20 > a more specific EID/prefix match, in which case you will explode the=20 > number of mappings (still not a good thing), No; not more mappings. The mapping would still be to a site border router for the destination's site, but the ETR could be deeply embedded within the site. The way it would work is that the encapsulated packets would be directed to a (globally routable) locator for a site border router, but once the packets reach the site they are forwarded to the ETR within the site by routing on the identifier in the inner header. Or, we could just leave the ETR at the site border routers themselves or at some middlebox within the site; the choice is up to the individual sites. > or you will impose=20 > suboptimal routing if multiple interior ETRs advertise the same=20 > EID/prefix. In the general case, there are only so many ways=20 > into and=20 > out of an end site, and so it's not clear what benefit you=20 > buy by moving=20 > these things toward the host, other than perhaps distributing the=20 > untunneling load, assuming the cost of doing so is huge to=20 > begin with (I=20 > do not believe it is). One benefit of locating the ETR close to the end system is that the closer one gets to the end system the more it tends to resemble true end-to-end. > ITRs are also best kept to a minimum, but it is less demanding on=20 > everyone else because we don't have to know about where you put your=20 > ITRs (although you still impose load in terms of determining the=20 > mapping). Still, each ITR is going to need to play the=20 > mapping game. Sure, and the ITR can do that even if it is co-resident on the same physical platform as the end system. > This means that either there is a predistributed and=20 > precomputed TIB, to=20 > borrow terminology from Juanjo, or you must reconstruct the entries=20 > realtime (or a mixture of both). I think you want to do as little of=20 > that as possible, no matter which way you slice it. It is=20 > true it would=20 > reduce your memory requirements on single devices, but it also adds=20 > complexity into your IGP which for most end sites is not there today. I don't follow this. IMHO, we can place the ITRs as close to the end systems as we like - even on the same physical platform as the end system - without incurring any scaling issues. =20 > The mapping function is again key here. Right, but we do have some candidates on the table. Thanks - Fred fred.l.templin@boeing.com _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 18 02:23: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 1He3ZH-0002TO-Bd; Wed, 18 Apr 2007 02:23:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1He3ZF-0002TG-L2 for ram@iab.org; Wed, 18 Apr 2007 02:23:01 -0400 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 1He3ZE-0003Hi-AA for ram@iab.org; Wed, 18 Apr 2007 02:23:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 17 Apr 2007 23:22:59 -0700 X-IronPort-AV: i="4.14,420,1170662400"; d="scan'208"; a="370384445:sNHT43583188" 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 l3I6MvZw004284; Tue, 17 Apr 2007 23:22:57 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l3I6MvZV016945; Wed, 18 Apr 2007 06:22:57 GMT 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, 17 Apr 2007 23:22:57 -0700 Received: from [192.168.0.4] ([10.21.152.102]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 17 Apr 2007 23:22:56 -0700 In-Reply-To: <200704171400.l3HE0VJ40487@merlot.juniper.net> References: <200704171400.l3HE0VJ40487@merlot.juniper.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3763D592-6460-4B71-B4AD-0E20B934D036@cisco.com> Content-Transfer-Encoding: 7bit From: Dino Farinacci Subject: Re: [RAM] Comment on draft-farinacci-lisp-00.txt (LISP) Date: Tue, 17 Apr 2007 23:22:55 -0700 To: Yakov Rekhter X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 18 Apr 2007 06:22:56.0862 (UTC) FILETIME=[012A27E0:01C78182] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=521; t=1176877377; x=1177741377; 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]=20Comment=20on=20draft-farinacci-lisp-00.txt=20 (LISP)=20 |Sender:=20; bh=3bDE+YnXYFt0I0xXdA8D2hcmY8npWnU8RqrxxZ0UKmY=; b=DxlPVILqE6sdv4sGOrq96RgTtGjIyudaI4nHzdI08GzfM5e2XRn9qipiBCd3bRbVjDYhz25q BG9f5xaqv+z5LOcki3c+ouqoiFLlhw08KtZdwthB0AtRKH0MNJRmD+KG; 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: d17f825e43c9aed4fd65b7edddddec89 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 > If an ISP does not use LISP for TE, then according to the above > none of the ISP's routers have to be modified, which means that such > an ISP does not need to deploy any ITRs/ETRs. And if neither hosts nor > local routers have to be modified, then none of the local routers > need to be ITRs/ETRs. So, where would the ITRs/ETRs be deployed ? There are ITR/ETRs used for the address separation. Those are deployed at sites. And there can be, optionally, TE-ITR/TE-ETR which are deployed in ISPs. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 19 04:30: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 1HeS2S-0000kF-GU; Thu, 19 Apr 2007 04:30:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeS2Q-0000k6-Ip for ram@iab.org; Thu, 19 Apr 2007 04:30:46 -0400 Received: from mtagate7.uk.ibm.com ([195.212.29.140]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeS2P-0007kc-4n for ram@iab.org; Thu, 19 Apr 2007 04:30:46 -0400 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 l3J8UiJ3153686 for ; Thu, 19 Apr 2007 08:30:44 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.3) with ESMTP id l3J8UiUA2650316 for ; Thu, 19 Apr 2007 09:30:44 +0100 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 l3J8UhKs030924 for ; Thu, 19 Apr 2007 09:30:43 +0100 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 l3J8UgIu030912 for ; Thu, 19 Apr 2007 09:30:42 +0100 Received: from [9.4.210.149] ([9.4.210.149]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA264492 for ; Thu, 19 Apr 2007 10:30:41 +0200 Message-ID: <462728B8.5090804@zurich.ibm.com> Date: Thu, 19 Apr 2007 10:30:48 +0200 From: Brian E Carpenter Organization: IBM User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) 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: 9466e0365fc95844abaf7c3f15a05c7d Subject: [RAM] [Fwd: I-D ACTION:draft-carpenter-idloc-map-cons-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 This may be of interest; comments more than welcome Brian -------- Original Message -------- Subject: I-D ACTION:draft-carpenter-idloc-map-cons-00.txt Date: Wed, 18 Apr 2007 15:50:02 -0400 From: Internet-Drafts@ietf.org Reply-To: internet-drafts@ietf.org To: i-d-announce@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : General Identifier-Locator Mapping Considerations Author(s) : B. Carpenter Filename : draft-carpenter-idloc-map-cons-00.txt Pages : 16 Date : 2007-4-18 This document presents various general considerations about the mapping between identifiers and locators at the network and routing level in the Internet. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-carpenter-idloc-map-cons-00.txt _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 19 09:19:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWXU-0002G5-D3; Thu, 19 Apr 2007 09:19:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeWXT-0002Fz-Gn for ram@iab.org; Thu, 19 Apr 2007 09:19:07 -0400 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeWXS-0006Rk-JM for ram@iab.org; Thu, 19 Apr 2007 09:19:07 -0400 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JGQYBO01.TC2 for ; Thu, 19 Apr 2007 15:19:00 +0200 X-Priority: 1 (High) To: ram@iab.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 19 Apr 2007 14:06:28 +0200 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 19/04/2007 15:18:58, Serialize complete at 19/04/2007 15:18:58 X-Spam-Score: 0.4 (/) X-Scan-Signature: 562cdc9baa87554b29d950396a30cf75 Subject: [RAM] TIDR using the IDENTIFIERS attribute 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="===============1023470573==" Errors-To: ram-bounces@iab.org This is a multipart message in MIME format. --===============1023470573== Content-Type: multipart/alternative; boundary="=_alternative 004282FCC12572C2_=" This is a multipart message in MIME format. --=_alternative 004282FCC12572C2_= Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi all, I am sending you the mail I promised on Monday.=20 I think we have mainly two problems to solve:=20 (1) scalability of the global BGP table, (2) BGP churn. (1) SCALABILITY OF THE ROUTING TABLE=20 We have several thousands of autonomous systems in the Internet, and we treat all of them in the same way whether they are transit or non-transit AS-es. But we shouldn=B4t forget that only 1/6 are transit AS-es. And most likely this fraction is decreasing over time (any figures?). In the draft on "Tunneled Inter-domain Routing (TIDR)" I presented a push method based on the use of tunnels which are announced using the LOCATOR attribute. It is the presence of the LOCATOR attribute what permits to say whether a prefix is a "locator prefix" or an "identifier prefix". This separation will allows us to treat these two types of prefixes differently. But this separation can be achieved either using the LOCATOR attribute to assign locators to identifiers, or by using the IDENTIFIERS attribute to specify which identifiers can be reached through the locator specified in the NLRI of the BGP update.=20 In TIDR, scalability of the routing table is achieved because whereas "locator prefixes" are still stored in the RIB, "identifier prefixes" are moved to the TIB. As a consequence of this, the RIB eventually will only store the "locator prefixes" of the transit AS-es. (2) BGP CHURN As Heiner Hummel pointed out "with Hierarchical Routing the routing churn rate will dramatically be reduced".=20 I think he is right, because with hierarchical routing not all parts of the network are equally important. So that, an announcement or withdrawal of an "identifier prefix" will be far less important than that of a "locator prefix". The addition of a new attribute to BGP (LOCATOR, IDENTIFIERS, or both) obviously increases the amount of information that must be flooded by BGP. But in my opinion, the main problem is not this increase in the amount of information but the fact that a change in a leaf AS using PI addressing implies to modify the RIB and FIB of all the routers in the DFZ. In other words, the problem is not to force every router in the entire DFZ to carry an advertisement for site X's PI-prefix. The most important problem is that it has to use this announcement for routing, i.e. it has to install it in the RIB and download it into the FIB. With TIDR things improve because this announcement will not modify the RIB but only the TIB. Therefore, if we want to reduce the effect of the route churn on the BGP convergence we will have to modify BGP so that a change in the identifier-locator map will not affect the interdomain routing system (more specifically the RIB of DFZ routers) but only the TIB. So, we need two types of BGP updates: "routing updates" and "mapping updates". Let's use for example the block 240.0.0.0/8 to assign "locator prefixes" to transit AS-es so that, for instance, AS1 will use the block 240.0.1.0/24 for "locator prefixes". Please notice that this is just an example to explain the inner workings of my proposal. I think it is very important to use a specific range of IP addresses for TIDR routing so that a transit AS is assigned an address block easy to identify. The ORIGIN attribute is a mandatory attribute that must be always present in any BGP update. At present this attribute can have one of the following values: - IGP: the NLRI is interior to the originating AS - EGP: NLRI learned via the EGP protocol - Incomplete: NLRI learned by some other means The ORIGIN=3DEGP value is no longer used. Therefore I propose to reinterpret this value as EXTERNAL (to keep the first letter the same), or to define a fourth value for the ORIGIN attribute, whatever is simpler. If the latter is simpler we could define ORIGIN=3DMAPPING to indicate that the BGP update is just for ID-LOC mapping. Bearing this in mind we proceed to distinguish the two aforementioned types of BGP updates: - "routing updates": these are the current type of updates. They carry ORIGIN IGP or INCOMPLETE. They are used to modify the RIB. - "mapping updates": they carry ORIGIN EXTERNAL or MAPPING, and are used to modify the TIB. They carry the IDENTIFIERS attribute to specify the set of "identifier prefixes" that can be reached through the locator specified in the NLRI of the update. They will be treated with a priority lower than "routing updates". With these two types of BGP updates we separate routing events (those affecting the interdomain infrastructure) from those updates caused by changes in the ID-LOC mapping. Following the above example, AS1 will generate "routing updates" to announce prefix 240.0.1.0/24 or even longer prefixes that will remain inside the interdomain routing infrastructure. What means that transit AS-es will never propagate these announcements to their leaf customers, for they are outside the interdomain infrastructure. And AS1 will also generate "mapping updates" to specify=20 within the IDENTIFIERS attribute which "identifier prefixes" can be accessed by sending tunneled traffic to the locator which is specified in the NLRI. Notes: a) I have continued to use LOCATOR as the name of the first new attribute that I proposed in the TIDR draft, but notice that this attribute can be used to store several locators. Therefore the name can be changed to LOCATORS. b) When I say PI-prefix I also mean a deaggregated PA-prefix. Any comments?. Regards, Juanjo --=_alternative 004282FCC12572C2_= Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable
Hi all,

I am sending you the mail I promised on Monday.

I think we have mainly two problems to solve:
(1) scalability of the global BGP t= able,
(2) BGP churn.

(1) SCALABILITY OF THE ROUTING TABLE
We have several thousands of autono= mous systems in the
Internet, and we treat all of them in the same way whether
they are transit or non-transit AS-= es. But we shouldn=B4t
forget that only 1/6 are transit AS= -es. And most likely
this fraction is decreasing over ti= me (any figures?).

In the draft on "Tunneled Inte= r-domain Routing (TIDR)"
I presented a push method based on the use of tunnels
which are announced using the LOCAT= OR attribute. It is
the presence of the LOCATOR attribu= te what permits to
say whether a prefix is a "loc= ator prefix" or an
"identifier prefix". This separation will allows us to
treat these two types of prefixes d= ifferently.

But this separation can be achieved either using the
LOCATOR attribute to assign locators to identifiers,
or by using the IDENTIFIERS attribu= te to specify which
identifiers can be reached through the locator specified
in the NLRI of the BGP update.

In TIDR, scalability of the routing table is achieved
because whereas "locator prefi= xes" are still stored in
the RIB, "identifier prefixes&= quot; are moved to the TIB.
As a consequence of this, the RIB e= ventually will
only store the "locator prefix= es" of the transit AS-es.


(2) BGP CHURN
As Heiner Hummel pointed out "= with Hierarchical Routing
the routing churn rate will dramati= cally be reduced".

I think he is right, because with h= ierarchical routing not
all parts of the network are equally important. So that,
an announcement or withdrawal of an "identifier prefix"
will be far less important than that of a "locator prefix".

The addition of a new attribute to BGP (LOCATOR, IDENTIFIERS,
or both) obviously increases the am= ount of information that
must be flooded by BGP. But in my o= pinion, the main problem
is not this increase in the amount of information but the
fact that a change in a leaf AS usi= ng PI addressing implies
to modify the RIB and FIB of all the routers in the DFZ.

In other words, the problem is not to force every router in
the entire DFZ to carry an advertis= ement for site X's
PI-prefix. The most important probl= em is that it has to use
this announcement for routing, i.e. it has to install it in
the RIB and download it into the FI= B. With TIDR things
improve because this announcement w= ill not modify the RIB
but only the TIB.

Therefore, if we want to reduce the effect of the route churn
on the BGP convergence we will have to modify BGP so that a
change in the identifier-locator map will not affect the
interdomain routing system (more sp= ecifically the RIB of
DFZ routers) but only the TIB. So, we need two types of
BGP updates: "routing updates&= quot; and "mapping updates".

Let's use for example the block 240= .0.0.0/8 to assign
"locator prefixes" to tra= nsit AS-es so that, for instance,
AS1 will use the block 240.0.1.0/24 for "locator prefixes".

Please notice that this is just an example to explain
the inner workings of my proposal. I think it is very
important to use a specific range of IP addresses for
TIDR routing so that a transit AS is assigned an address
block easy to identify.

The ORIGIN attribute is a mandatory attribute that must
be always present in any BGP update. At present this
attribute can have one of the follo= wing values:
  - IGP: the NLRI is interior to the originating AS
  - EGP: NLRI learned via the EGP protocol
  - Incomplete: NLRI learned by some other means

The ORIGIN=3DEGP value is no longer= used. Therefore I
propose to reinterpret this value as EXTERNAL (to keep
the first letter the same), or to d= efine a fourth value
for the ORIGIN attribute, whatever is simpler. If the
latter is simpler we could define O= RIGIN=3DMAPPING to
indicate that the BGP update is just for ID-LOC mapping.

Bearing this in mind we proceed to distinguish the two
aforementioned types of BGP updates= :
  - "routing updates"= ;: these are the current type of
    updates. They carry O= RIGIN IGP or INCOMPLETE.
    They are used to modi= fy the RIB.
  - "mapping updates"= ;: they carry ORIGIN EXTERNAL or
    MAPPING, and are used to modify the TIB. They
    carry the IDENTIFIERS attribute to specify the
    set of "identifi= er prefixes" that can be reached
    through the locator s= pecified in the NLRI of the
    update. They will be treated with a priority
    lower than "rout= ing updates".

With these two types of BGP updates we separate routing
events (those affecting the interdo= main infrastructure)
from those updates caused by changes in the ID-LOC mapping.

Following the above example, AS1 wi= ll generate "routing
updates" to announce prefix 24= 0.0.1.0/24 or even longer
prefixes that will remain inside the interdomain routing
infrastructure. What means that tra= nsit AS-es will never
propagate these announcements to th= eir leaf customers,
for they are outside the interdomain infrastructure.

And AS1 will also generate "ma= pping updates" to specify
within the IDENTIFIERS attribute wh= ich "identifier prefixes"
can be accessed by sending tunneled traffic to the locator
which is specified in the NLRI.

Notes:
a) I have continued to use LOCATOR as the name of the first
   new attribute that I p= roposed in the TIDR draft, but
   notice that this attri= bute can be used to store several
   locators. Therefore the name can be changed to LOCATORS.
b) When I say PI-prefix I also mean a deaggregated PA-prefix.


Any comments?.

Regards,
Juanjo

--=_alternative 004282FCC12572C2_=-- --===============1023470573== 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 --===============1023470573==-- From ram-bounces@iab.org Thu Apr 19 11:08:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYFU-0007q0-1c; Thu, 19 Apr 2007 11:08:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HeYFS-0007pn-KT for ram@iab.org; Thu, 19 Apr 2007 11:08:38 -0400 Received: from diotima.switch.ch ([2001:620:0:4:203:baff:fe4c:d751]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HeYFQ-00037B-Sm for ram@iab.org; Thu, 19 Apr 2007 11:08:38 -0400 Received: (from leinen@localhost) by diotima.switch.ch (8.14.0+Sun/8.14.0) id l3JF8XxV016487; Thu, 19 Apr 2007 17:08:33 +0200 (CEST) X-Authentication-Warning: diotima.switch.ch: leinen set sender to simon@limmat.switch.ch using -f From: Simon Leinen To: JUAN-JOSE.ADAN@giss.seg-social.es Subject: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] In-Reply-To: (JUAN-JOSE ADAN's message of "Thu, 19 Apr 2007 14:06:28 +0200") References: X-Face: 1Nk*r=:$IBBb8|TyRB'2WSY6u:BzMO7N)#id#-4_}MsU5?vTI?dez|JiutW4sKBLjp.l7, F 7QOld^hORRtpCUj)!cP]gtK_SyK5FW(+o"!or:v^C^]OxX^3+IPd\z, @ttmwYVO7l`6OXXYR` Date: Thu, 19 Apr 2007 17:08:33 +0200 Message-ID: User-Agent: Gnus/5.110006 (No Gnus v0.6) Emacs/22.0.98 (usg-unix-v) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -2.8 (--) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable JUAN-JOSE ADAN writes: > (1) SCALABILITY OF THE ROUTING TABLE=20 > We have several thousands of autonomous systems in the > Internet, and we treat all of them in the same way whether > they are transit or non-transit AS-es. But we shouldn=C2=B4t > forget that only 1/6 are transit AS-es. And most likely > this fraction is decreasing over time (any figures?). You could look at http://bgp.potaroo.net/index-bgp.html and, for one or three suitable ASes, check out the history files of terminal, transit-only, and mixed ASes, e.g.: http://bgp.potaroo.net/1239/bgp-as-term.txt http://bgp.potaroo.net/1239/bgp-transit.txt http://bgp.potaroo.net/1239/bgp-mixedas.txt I wrote a quick Perl script (attached) and ran it on the AS1239 files. The results suggest that the ratio of transit (-only and mixed) ASes to total has remained pretty stable over the past years (modulo a dot-com-bubble/burst bump :-). According to this definition, the ratio is more like 29%, not the 1/6 you claim. : leinen@diotima[ram]; perl hack.pl | awk '{ print $6, $5 }' | uniq -1 30.85% 1998 31.87% 1999 27.96% 2000 28.73% 2001 28.15% 2002 27.07% 2003 27.84% 2004 28.68% 2005 28.50% 2006 29.14% 2007 (uniq -1 drops all but the first measurement for a given year, so these are the respective ~January 1 numbers.) Maybe your definition of a transit AS differs from Geoff's? --=20 Simon. --=-=-= Content-Type: text/x-perl-script Content-Disposition: inline; filename=hack.pl #!/usr/local/bin/perl -w use strict; my @classes = qw(as-term transit mixedas); my %by_date = (); foreach my $class (@classes) { my $file = "bgp-$class.txt"; open FILE, $file or die "Cannot open $file: $!"; while () { next if /^-1 \d+$/; die "Malformed line: $_" unless /^(\d+) (\d+)$/; $by_date{$1}->{$class} = $2; } close FILE or die "Cannot close $file: $!"; } foreach my $date (sort { $a <=> $b } keys %by_date) { my $by_class = $by_date{$date}; my $term = $by_class->{'as-term'}; my $transit_only = $by_class->{'transit'}; my $mixed = $by_class->{'mixedas'}; next if !defined $term or !defined $transit_only or !defined $mixed; print scalar localtime $date; my $transit = $transit_only + $mixed; printf " %5.2f%%", ($transit*100.0) / ($transit + $term); print "\n"; } 1; --=-=-= 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 --=-=-=-- From ram-bounces@iab.org Thu Apr 19 15:16:50 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hec6o-0001Bn-Fh; Thu, 19 Apr 2007 15:15:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hec6m-00017W-Db for ram@iab.org; Thu, 19 Apr 2007 15:15:56 -0400 Received: from smtp-5.smtp.ucla.edu ([169.232.47.137]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hec6k-0003Kg-Tf for ram@iab.org; Thu, 19 Apr 2007 15:15:56 -0400 Received: from mail.ucla.edu (mail.ucla.edu [169.232.47.146]) by smtp-5.smtp.ucla.edu (8.13.8/8.13.8) with ESMTP id l3JJFoCj032426; Thu, 19 Apr 2007 12:15:51 -0700 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 l3JJFo6p026379 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 19 Apr 2007 12:15:50 -0700 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: <64256423-0077-4A3D-9B3B-E742D616A704@cs.ucla.edu> Content-Transfer-Encoding: quoted-printable From: "Ricardo V. Oliveira" Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] Date: Thu, 19 Apr 2007 12:17:44 -0700 To: Simon Leinen X-Mailer: Apple Mail (2.752.2) X-Probable-Spam: no X-Scanned-By: smtp.ucla.edu on 169.232.47.137 X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: JUAN-JOSE.ADAN@giss.seg-social.es, 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 Yes, our measurements also confirm Simon numbers. Roughly speaking, =20 about 1/3 of ASes are transit, but they originate 2/3 of the prefixes. --Ricardo On Apr 19, 2007, at 8:08 AM, Simon Leinen wrote: > JUAN-JOSE ADAN writes: >> (1) SCALABILITY OF THE ROUTING TABLE >> We have several thousands of autonomous systems in the >> Internet, and we treat all of them in the same way whether >> they are transit or non-transit AS-es. But we shouldn=B4t >> forget that only 1/6 are transit AS-es. And most likely >> this fraction is decreasing over time (any figures?). > > You could look at > > http://bgp.potaroo.net/index-bgp.html > > and, for one or three suitable ASes, check out the history files of > terminal, transit-only, and mixed ASes, e.g.: > > http://bgp.potaroo.net/1239/bgp-as-term.txt > http://bgp.potaroo.net/1239/bgp-transit.txt > http://bgp.potaroo.net/1239/bgp-mixedas.txt > > I wrote a quick Perl script (attached) and ran it on the AS1239 files. > The results suggest that the ratio of transit (-only and mixed) ASes > to total has remained pretty stable over the past years (modulo a > dot-com-bubble/burst bump :-). According to this definition, the > ratio is more like 29%, not the 1/6 you claim. > > : leinen@diotima[ram]; perl hack.pl | awk '{ print $6, $5 }' | uniq -1 > 30.85% 1998 > 31.87% 1999 > 27.96% 2000 > 28.73% 2001 > 28.15% 2002 > 27.07% 2003 > 27.84% 2004 > 28.68% 2005 > 28.50% 2006 > 29.14% 2007 > > (uniq -1 drops all but the first measurement for a given year, so > these are the respective ~January 1 numbers.) > > Maybe your definition of a transit AS differs from Geoff's? > --=20 > Simon. > #!/usr/local/bin/perl -w > > use strict; > > my @classes =3D qw(as-term transit mixedas); > > my %by_date =3D (); > > foreach my $class (@classes) { > my $file =3D "bgp-$class.txt"; > open FILE, $file or die "Cannot open $file: $!"; > while () { > next if /^-1 \d+$/; > die "Malformed line: $_" unless /^(\d+) (\d+)$/; > $by_date{$1}->{$class} =3D $2; > } > close FILE or die "Cannot close $file: $!"; > } > foreach my $date (sort { $a <=3D> $b } keys %by_date) { > my $by_class =3D $by_date{$date}; > my $term =3D $by_class->{'as-term'}; > my $transit_only =3D $by_class->{'transit'}; > my $mixed =3D $by_class->{'mixedas'}; > next if !defined $term or !defined $transit_only or !defined =20 > $mixed; > print scalar localtime $date; > my $transit =3D $transit_only + $mixed; > printf " %5.2f%%", ($transit*100.0) / ($transit + $term); > print "\n"; > } > 1; > _______________________________________________ > 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 Thu Apr 19 22:45:43 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hej7w-0006A3-OI; Thu, 19 Apr 2007 22:45:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hej7v-00069v-NJ for ram@iab.org; Thu, 19 Apr 2007 22:45:35 -0400 Received: from ppp162-123.static.internode.on.net ([150.101.162.123] helo=gair.firstpr.com.au) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hej7u-0002xV-7y for ram@iab.org; Thu, 19 Apr 2007 22:45:35 -0400 Received: from [10.0.0.8] (zita.firstpr.com.au [10.0.0.8]) by gair.firstpr.com.au (Postfix) with ESMTP id C4E1059E44; Fri, 20 Apr 2007 12:45:26 +1000 (EST) Message-ID: <46282933.2020200@firstpr.com.au> Date: Fri, 20 Apr 2007 12:45:07 +1000 From: Robin Whittle Organization: First Principles User-Agent: Mozilla Thunderbird 1.0.7 (Windows/20050923) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Paper on FIB structures References: <461F59CA.20709@firstpr.com.au> In-Reply-To: <461F59CA.20709@firstpr.com.au> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.1 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 think I found the paper: > A list member told me of a "Stanford paper which covers some very > elegant FIB structures, and describes some of the others that are > considered. These papers talk about the trade-offs in number of > look ups, amount of memory, etc..." Algorithms for Packet Classification Pankaj Gupta and Nick McKeown IEEE Network, March 2001 http://tiny-tera.stanford.edu/~nickm/papers/classification_tutorial_01.pdf I was happy - and not surprised - to find a much earlier proposal similar to my SRAM-forwarding idea. In 1998, Nick McKeown and colleagues suggested using the to 24 IPv4 address to directly access RAM: Routing Lookups in Hardware at Memory Access Speeds. Pankaj Gupta, Steven Lin and Nick McKeown IEEE INFOCOM April 1998, Vol 3, pp. 1240-1247. http://tiny-tera.stanford.edu/~nickm/papers/Infocom98_lookup.pdf Nick McKeown's site has a large number of papers and presentations: http://tiny-tera.stanford.edu/~nickm/ - Robin _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 20 05:51:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hepli-0008Fa-2x; Fri, 20 Apr 2007 05:51:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heplf-00087g-Ao for ram@iab.org; Fri, 20 Apr 2007 05:51:03 -0400 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 1Heplc-0001eV-PT for ram@iab.org; Fri, 20 Apr 2007 05:51:03 -0400 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JGSJCX00.U5T; Fri, 20 Apr 2007 11:50:57 +0200 In-Reply-To: <64256423-0077-4A3D-9B3B-E742D616A704@cs.ucla.edu> X-Priority: 1 (High) To: "Ricardo V. Oliveira" Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Fri, 20 Apr 2007 11:50:54 +0200 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 20/04/2007 11:50:55, Serialize complete at 20/04/2007 11:50:55 X-Spam-Score: 0.3 (/) X-Scan-Signature: 200d029292fbb60d25b263122ced50fc 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="===============0043135292==" Errors-To: ram-bounces@iab.org This is a multipart message in MIME format. --===============0043135292== Content-Type: multipart/alternative; boundary="=_alternative 003619B1C12572C3_=" This is a multipart message in MIME format. --=_alternative 003619B1C12572C3_= Content-Type: text/plain; charset="US-ASCII" Ricardo, Simon: Thank you for your comments. Please see below. "Ricardo V. Oliveira" wrote on 19/04/2007 21:17:44: > Yes, our measurements also confirm Simon numbers. Roughly speaking, > about 1/3 of ASes are transit, but they originate 2/3 of the prefixes. > > --Ricardo > > On Apr 19, 2007, at 8:08 AM, Simon Leinen wrote: > > > > > I wrote a quick Perl script (attached) and ran it on the AS1239 files. > > The results suggest that the ratio of transit (-only and mixed) ASes > > to total has remained pretty stable over the past years (modulo a > > dot-com-bubble/burst bump :-). According to this definition, the > > ratio is more like 29%, not the 1/6 you claim. The last RIS Statistics Report provided by RIPE (http://www.ris.ripe.net/weekly-report/reports/20070409-20070416.html) shows the following: Distribution of AS number wrt Leaf, Transit. RIS rrc00 rrc01 rrc02 rrc03 rrc04 rrc05 Leaf 21120 21197 21132 5012 21153 19944 21252 Transit 4122 3971 3900 522 3916 3518 3801 Transit-only 142 136 133 963 133 193 132 Total 25384 25304 25165 6497 25202 23655 25185 If we take the first column we have: 25384 / (4122 + 142) = 5.95 Therefore, roughly speaking, transit AS-es are 1/6 of the total. > > Maybe your definition of a transit AS differs from Geoff's? > > -- > > Simon. I think this definition is the same for all of us, isn't it?. Am I missing something?. At first sight one should think that 1/3 are too many transit AS-es but reality always has the last word. Regards, Juanjo --=_alternative 003619B1C12572C3_= Content-Type: text/html; charset="US-ASCII"
Ricardo, Simon:

Thank you for your comments. Please see below.

"Ricardo V. Oliveira" <rveloso@cs.ucla.edu> wrote on 19/04/2007 21:17:44:

> Yes, our measurements also confirm Simon numbers. Roughly speaking,  
> about 1/3 of ASes are transit, but they originate 2/3 of the prefixes.
>
> --Ricardo
>
> On Apr 19, 2007, at 8:08 AM, Simon Leinen wrote:
>
> >
> > I wrote a quick Perl script (attached) and ran it on the AS1239 files.
> > The results suggest that the ratio of transit (-only and mixed) ASes
> > to total has remained pretty stable over the past years (modulo a
> > dot-com-bubble/burst bump :-).  According to this definition, the
> > ratio is more like 29%, not the 1/6 you claim.
The last RIS Statistics Report provided by RIPE
(http://www.ris.ripe.net/weekly-report/reports/20070409-20070416.html)
shows the following:

Distribution of AS number wrt Leaf, Transit.

                 RIS         rrc00         rrc01         rrc02         rrc03         rrc04         rrc05        
Leaf           21120         21197         21132          5012         21153         19944         21252        
Transit         4122          3971          3900           522          3916          3518          3801          
Transit-only     142           136           133           963           133           193           132          
Total          25384         25304         25165          6497         25202         23655         25185        


If we take the first column we have:

25384 / (4122 + 142) = 5.95

Therefore, roughly speaking, transit AS-es are 1/6 of the total.

> > Maybe your definition of a transit AS differs from Geoff's?
> > --
> > Simon.

I think this definition is the same for all of us, isn't it?.
Am I missing something?.

At first sight one should think that 1/3 are too many transit AS-es
but reality always has the last word.

Regards,
Juanjo --=_alternative 003619B1C12572C3_=-- --===============0043135292== 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 --===============0043135292==-- From ram-bounces@iab.org Fri Apr 20 08:06:03 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HersF-0002l1-C5; Fri, 20 Apr 2007 08:05:59 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HersD-0002kJ-K9 for ram@iab.org; Fri, 20 Apr 2007 08:05:57 -0400 Received: from e32.co.us.ibm.com ([32.97.110.150]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HersC-0006PH-9i for ram@iab.org; Fri, 20 Apr 2007 08:05:57 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e32.co.us.ibm.com (8.12.11.20060308/8.13.8) with ESMTP id l3KC3AqB005625 for ; Fri, 20 Apr 2007 08:03:10 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l3KC5tEB133020 for ; Fri, 20 Apr 2007 06:05:55 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l3KC5tCo003261 for ; Fri, 20 Apr 2007 06:05:55 -0600 Received: from cichlid (wecm-9-67-207-252.wecm.ibm.com [9.67.207.252]) by d03av02.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l3KC5p9k003030 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 20 Apr 2007 06:05:54 -0600 Received: from cichlid (localhost.localdomain [127.0.0.1]) by cichlid (8.13.8/8.12.5) with ESMTP id l3KC4Q8r010242 for ; Fri, 20 Apr 2007 08:04:27 -0400 Message-Id: <200704201204.l3KC4Q8r010242@cichlid> To: ram@iab.org Date: Fri, 20 Apr 2007 08:04:26 -0400 From: Thomas Narten X-Spam-Score: 1.4 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [RAM] Weekly posting summary for 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 Total of 64 messages in the last 7 days. script run at: Fri Apr 20 00:53:03 EDT 2007 Messages | Bytes | Who --------+------+--------+----------+------------------------ 20.31% | 13 | 21.63% | 90841 | dino@cisco.com 15.62% | 10 | 10.73% | 45057 | yakov@juniper.net 10.94% | 7 | 10.01% | 42039 | fred.l.templin@boeing.com 9.38% | 6 | 7.87% | 33069 | lear@cisco.com 6.25% | 4 | 6.92% | 29081 | rw@firstpr.com.au 6.25% | 4 | 4.20% | 17634 | jnc@mercury.lcs.mit.edu 3.12% | 2 | 7.19% | 30194 | juan-jose.adan@giss.seg-social.es 4.69% | 3 | 5.31% | 22318 | marcelo@it.uc3m.es 1.56% | 1 | 7.67% | 32215 | lixia@cs.ucla.edu 4.69% | 3 | 4.30% | 18058 | tli@cisco.com 4.69% | 3 | 3.67% | 15435 | brc@zurich.ibm.com 4.69% | 3 | 3.39% | 14236 | pds@lugs.com 1.56% | 1 | 1.61% | 6743 | rveloso@cs.ucla.edu 1.56% | 1 | 1.52% | 6400 | simon@limmat.switch.ch 1.56% | 1 | 1.47% | 6190 | bonaventure@info.ucl.ac.be 1.56% | 1 | 1.26% | 5302 | christopher.morrow@verizonbusiness.com 1.56% | 1 | 1.25% | 5232 | narten@us.ibm.com --------+------+--------+----------+------------------------ 100.00% | 64 |100.00% | 420044 | Total _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 20 08:59:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heshm-0005et-RE; Fri, 20 Apr 2007 08:59:14 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Heshl-0005em-0f for ram@iab.org; Fri, 20 Apr 2007 08:59:13 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Heshj-0003UM-Nx for ram@iab.org; Fri, 20 Apr 2007 08:59:12 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id AE7B2198672 for ; Fri, 20 Apr 2007 15:59:10 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6CF6719866A for ; Fri, 20 Apr 2007 15:59:10 +0300 (EEST) Message-ID: <4628B91F.1050707@piuha.net> Date: Fri, 20 Apr 2007 15:59:11 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ram@iab.org Subject: Re: [RAM] Weekly posting summary for ram@iab.org References: <200704201204.l3KC4Q8r010242@cichlid> In-Reply-To: <200704201204.l3KC4Q8r010242@cichlid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Spam-Score: 1.4 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 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 By the way, in case people need to search something from discussions on this list, I added RAM, RRG, and Architecture- discuss list archives to Lars Eggert's IETF mailing list search tool. If you want to search something about ICMP in the routing and addressing related-discussions, for instance, enter the search string "ICMP more:roap" and you will see the relevant e-mails. Here's the URL: http://www.google.com/coop/cse?cx=006728497408158459967%3Aybxjdw-bjjw Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 21 03:03:05 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf9cS-0003dP-Ik; Sat, 21 Apr 2007 03:02:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hf9cR-0003d4-DI for ram@iab.org; Sat, 21 Apr 2007 03:02:51 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hf9cP-0000jM-EJ for ram@iab.org; Sat, 21 Apr 2007 03:02:51 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C38BF198676; Sat, 21 Apr 2007 10:02:47 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7CBDA198672; Sat, 21 Apr 2007 10:02:47 +0300 (EEST) Message-ID: <4629B719.7070407@piuha.net> Date: Sat, 21 Apr 2007 10:02:49 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: marcelo bagnulo braun Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> In-Reply-To: <25ecebd4d02476187199445d63130075@it.uc3m.es> 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: 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 Dino, Marcello, >> >> Yes, understand. Lixia made the same suggestion using the DNS >> protocol. That is use DNS the protocol as your query/reply protocol >> but don't run it on UDP 53. >> >> But I have to beg the question, why people think this is the long >> pole in the tent? That is designing a straight-forward protocol >> shouldn't be hard or time consuming. > > imho, established well known protocols that have already been tested > and are stable are better choice than new protocols, that need to > mature. Of course, this only if we don't overload existent usages. For > that reason, i think that if we can reuse the protocol but maybe not > the actual current system, seems the best tradeoff (of course if the > protocols do provide the required functionality, which is not at all > clear yet) At this time, I think its much more interesting to talk about the properties of the mapping system and protocol than to make a decision on reuse vs. new protocol. Push vs. pull, dynamics, security properties, trust model, scalability requirements, aggregated vs. flat, etc. that you talked about in the rest of this thread are the important questions now. Of course, its useful to think about what the real-world implementation of the concepts could be, e.g., a new BGP instance, but lets not get hang up on the protocol selection just yet. Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 21 06:50:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfDAZ-00074p-Gv; Sat, 21 Apr 2007 06:50:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfDAY-000728-AB for ram@iab.org; Sat, 21 Apr 2007 06:50:18 -0400 Received: from mercury.lcs.mit.edu ([18.26.0.122]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfDAX-0003rL-4E for ram@iab.org; Sat, 21 Apr 2007 06:50:18 -0400 Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id A6F48872E6; Sat, 21 Apr 2007 06:50:12 -0400 (EDT) To: ram@iab.org Message-Id: <20070421105012.A6F48872E6@mercury.lcs.mit.edu> Date: Sat, 21 Apr 2007 06:50:12 -0400 (EDT) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: jnc@mercury.lcs.mit.edu Subject: [RAM] Re: ID/loc mapping distribution protocol 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: Jari Arkko > the properties of the mapping system and protocol than to make a > decision on reuse vs. new protocol. Push vs. pull, dynamics, security > properties, trust model, scalability requirements, aggregated vs. > flat, etc. .. are the important questions now. ... > .. but lets not get hang up on the protocol selection just yet. Definitely. First we should figure out what the optimal design would be, and then we can look at what we already have and decide if we can reuse or adapt something we already have. At that point, we will be in a position to decide if what we save by reusing something outweighs the costs of using something that's not exactly what we need. Frankly, when I look at the lifetime these things will be deployed over (if they are successful), along with the size of the deployed base if so, the amount to be saved looks pretty miniscule in comparison. However, realistically, the resources we might save over the life-cycle aren't necessariliy available now, so we may be forced to incur costs down the line by using something non-optimal. Noel _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 21 17:13:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfMtZ-0000Fg-IE; Sat, 21 Apr 2007 17:13:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfMtY-0000Fb-CG for ram@iab.org; Sat, 21 Apr 2007 17:13:24 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfMtX-00005G-2o for ram@iab.org; Sat, 21 Apr 2007 17:13:24 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2007 14:13:22 -0700 X-IronPort-AV: i="4.14,436,1170662400"; d="scan'208"; a="138880474:sNHT43568271" 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 l3LLDMvs030766; Sat, 21 Apr 2007 14:13:22 -0700 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 l3LLDHZT000195; Sat, 21 Apr 2007 21:13:18 GMT 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); Sat, 21 Apr 2007 14:13:17 -0700 Received: from [10.253.202.170] ([10.21.144.143]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Apr 2007 14:13:16 -0700 In-Reply-To: <4629B719.7070407@piuha.net> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> <4629B719.7070407@piuha.net> 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: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Sat, 21 Apr 2007 14:13:15 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Apr 2007 21:13:16.0767 (UTC) FILETIME=[E12606F0:01C78459] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=639; t=1177190002; x=1178054002; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=XQyRzDMIRjUjzLZXWWdmv2WxDSiCtIng2Wh7BhGL9qg=; b=ZmXwAjZ4Uqo4gVcUZQuxeWt2tg2rchd2nj+LWRjdLqHaYaT53SzTEJy7Wb+WG1qCzLvHj71e htiKyl2VHROFkOZgeikaDx/pqLWq12EHSsdBEvIZnph8WfK+6zliF19m; 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: 7a6398bf8aaeabc7a7bb696b6b0a2aad 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 > At this time, I think its much more interesting to talk about the > properties of the mapping system and protocol than to make a > decision on reuse vs. new protocol. Push vs. pull, dynamics, > security properties, trust model, scalability requirements, > aggregated vs. flat, etc. that you talked about in the rest of > this thread are the important questions now. Of course, its > useful to think about what the real-world implementation of > the concepts could be, e.g., a new BGP instance, but lets > not get hang up on the protocol selection just yet. Jari, I understand your point, but what are we waiting for? Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Sat Apr 21 18:16:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfNsG-0004mE-Vi; Sat, 21 Apr 2007 18:16:08 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfNsF-0004iP-D4 for ram@iab.org; Sat, 21 Apr 2007 18:16:07 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfNsE-0000t7-2v for ram@iab.org; Sat, 21 Apr 2007 18:16:07 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2007 15:16:05 -0700 X-IronPort-AV: i="4.14,436,1170662400"; d="scan'208"; a="138888607:sNHT47032083" 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 l3LMG5BH028829; Sat, 21 Apr 2007 15:16:05 -0700 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 l3LMFvMF012585; Sat, 21 Apr 2007 22:15:57 GMT 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, 21 Apr 2007 15:15:56 -0700 Received: from [192.168.0.100] ([10.21.152.116]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 21 Apr 2007 15:15:56 -0700 In-Reply-To: References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> <4629B719.7070407@piuha.net> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <3B65F69D-979B-4AE2-86DD-78B1BF2475AB@cisco.com> Content-Transfer-Encoding: 7bit From: Tony Li Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Sat, 21 Apr 2007 15:15:55 -0700 To: Dino Farinacci X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 21 Apr 2007 22:15:56.0661 (UTC) FILETIME=[A2385250:01C78462] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=1135; t=1177193765; x=1178057765; c=relaxed/simple; s=sjdkim3002; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=R9mClLhARHzE3+KR1gpqFFbw4SitilzacRZlfHkdhOs=; b=c2Ow27Ryh4tHh4/tx0sWWhMPez+L296dkMyan4YcS6Tral7w7oF+oB/RsgELsQAgXYIaeYEG FyevJPF+kTT6VWxK9ojRt2o2P4W2ZvBxbXT5BZMSAKnZmRqnMfmHFqO8; Authentication-Results: sj-dkim-3; header.From=tli@cisco.com; dkim=pass (sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 Apr 21, 2007, at 2:13 PM, Dino Farinacci wrote: >> At this time, I think its much more interesting to talk about the >> properties of the mapping system and protocol than to make a >> decision on reuse vs. new protocol. Push vs. pull, dynamics, >> security properties, trust model, scalability requirements, >> aggregated vs. flat, etc. that you talked about in the rest of >> this thread are the important questions now. Of course, its >> useful to think about what the real-world implementation of >> the concepts could be, e.g., a new BGP instance, but lets >> not get hang up on the protocol selection just yet. > > Jari, I understand your point, but what are we waiting for? I don't think that Jari is suggesting that we wait. I think that he's suggesting that we think first at the conceptual level and work through the problems that we can see there before we dive into the details. The solution space is pretty large and implementing each and every point in the solution space is probably not the most efficient (or quickest) approach to getting to the solution that we want. Tony _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 23 00:28:56 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqAI-0001fn-Mn; Mon, 23 Apr 2007 00:28:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqAG-0001fb-3Y for ram@iab.org; Mon, 23 Apr 2007 00:28:36 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfqAE-0001zD-Cu for ram@iab.org; Mon, 23 Apr 2007 00:28:36 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id C0A37198676; Mon, 23 Apr 2007 07:28:32 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 7882F198672; Mon, 23 Apr 2007 07:28:32 +0300 (EEST) Message-ID: <462C35F1.8090402@piuha.net> Date: Mon, 23 Apr 2007 07:28:33 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: Tony Li , Dino Farinacci Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> <4629B719.7070407@piuha.net> <3B65F69D-979B-4AE2-86DD-78B1BF2475AB@cisco.com> In-Reply-To: <3B65F69D-979B-4AE2-86DD-78B1BF2475AB@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: 79899194edc4f33a41f49410777972f8 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 Tony, Dino, > I don't think that Jari is suggesting that we wait. I think that he's > suggesting that we think first at the conceptual level and work > through the problems that we can see there before we dive into the > details. > > The solution space is pretty large and implementing each and every > point in the solution space is probably not the most efficient (or > quickest) approach to getting to the solution that we want. Right. And I don't think we should wait, either -- if you have a mapping system please write it up in a draft & implement & test. We need that level of concreteness to understand whether our ideas really work or not. I was merely suggesting that we do not use a lot of energy on the list to debate whether the protocol is new or reused. There are other, more worthy topics to be debated... Jari _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 23 00:49:08 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqU3-0000L8-Ge; Mon, 23 Apr 2007 00:49:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HfqU2-0000L0-0O for ram@iab.org; Mon, 23 Apr 2007 00:49:02 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HfqU0-0007LB-NF for ram@iab.org; Mon, 23 Apr 2007 00:49:01 -0400 Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-5.cisco.com with ESMTP; 22 Apr 2007 21:49:01 -0700 X-IronPort-AV: i="4.14,439,1170662400"; d="scan'208"; a="414443945:sNHT44533360" 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 l3N4mxls027000; Sun, 22 Apr 2007 21:48:59 -0700 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 l3N4mtZT028687; Mon, 23 Apr 2007 04:48:59 GMT 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); Sun, 22 Apr 2007 21:48:55 -0700 Received: from [192.168.0.4] ([10.21.154.222]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 22 Apr 2007 21:48:55 -0700 In-Reply-To: <462C35F1.8090402@piuha.net> References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es> <4629B719.7070407@piuha.net> <3B65F69D-979B-4AE2-86DD-78B1BF2475AB@cisco.com> <462C35F1.8090402@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: Dino Farinacci Subject: Re: ID/loc mapping distribution protocol (was Re: [RAM] Incremental Deployment of LISP Date: Sun, 22 Apr 2007 21:48:55 -0700 To: Jari Arkko X-Mailer: Apple Mail (2.752.3) X-OriginalArrivalTime: 23 Apr 2007 04:48:55.0262 (UTC) FILETIME=[B2930FE0:01C78562] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=436; t=1177303740; x=1178167740; 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=20ID/loc=20mapping=20distribution=20protocol=20(was=20R e=3A=20[RAM]=20Incremental=20Deployment=20of=20LISP |Sender:=20; bh=ROFQCAn9XghRUYxbQTqFBHljsJtcPBhp5qU2MjhqBkA=; b=dKo20AdGWW4gInO54mIJmq/2nWKFPPoov+u7ekOJt+ansZOVEUjjQJzVZPymOnqqTPbbrC/P rrAHEZkylC1SDaz2XT+yyxq0Pdv3PCqdL/vVlv+6vleBmc3cFqBgd7x1; 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: d17f825e43c9aed4fd65b7edddddec89 Cc: Tony Li , 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 > Right. And I don't think we should wait, either -- if you have a > mapping > system please write it up in a draft & implement & test. We need that > level of concreteness to understand whether our ideas really work > or not. I was merely suggesting that we do not use a lot of energy > on the list to debate whether the protocol is new or reused. There > are other, more worthy topics to be debated... Okay, sure. Dino _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Mon Apr 23 11:19:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0KS-0000B1-St; Mon, 23 Apr 2007 11:19:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hg0KR-0000Aw-RD for ram@iab.org; Mon, 23 Apr 2007 11:19:47 -0400 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 1Hg0KQ-0008KD-IF for ram@iab.org; Mon, 23 Apr 2007 11:19:47 -0400 Received: from stl-av-01.boeing.com (stl-av-01.boeing.com [192.76.190.6]) by stl-smtpout-01.ns.cs.boeing.com (8.13.6/8.13.6/TEST_SMTPIN) with ESMTP id l3NFJjiM018066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 23 Apr 2007 10:19:45 -0500 (CDT) Received: from stl-av-01.boeing.com (localhost [127.0.0.1]) by stl-av-01.boeing.com (8.13.6/8.13.6/DOWNSTREAM_RELAY) with ESMTP id l3NFJit6009673; Mon, 23 Apr 2007 10:19:45 -0500 (CDT) Received: from XCH-NWBH-11.nw.nos.boeing.com (xch-nwbh-11.nw.nos.boeing.com [130.247.55.84]) by stl-av-01.boeing.com (8.13.6/8.13.6/UPSTREAM_RELAY) with ESMTP id l3NFJidQ009650; Mon, 23 Apr 2007 10:19:44 -0500 (CDT) 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); Mon, 23 Apr 2007 08:19:44 -0700 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: ID/loc mapping distribution protocol (was Re: [RAM] IncrementalDeployment of LISP Date: Mon, 23 Apr 2007 08:19:43 -0700 Message-ID: <39C363776A4E8C4A94691D2BD9D1C9A1029ED73F@XCH-NW-7V2.nw.nos.boeing.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ID/loc mapping distribution protocol (was Re: [RAM] IncrementalDeployment of LISP Thread-Index: AceFYryJzhTo08rpR12T7puYxdQfvgAVgKMA References: <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <20070329192859.4630E87323@mercury.lcs.mit.edu> <98D229CF-EC80-4274-AF15-0F3467BC8E05@cisco.com> <460D253A.100@cisco.com> <39C363776A4E8C4A94691D2BD9D1C9A101774860@XCH-NW-7V2.nw.nos.boeing.com> <5.0.0.25.2.20070330163406.033d47e0@zircon.juniper.net> <41366ffb2e8e157b4a6b24f100a6e1f4@it.uc3m.es> <979941FF-8400-44B6-AE0D-EA9CCD54B69B@cisco.com> <922351a8b609dc4cf2072fd878b609cb@it.uc3m.es> <816668963e0ee48143c31b9006c551d0@it.uc3m.es> <0073B999-7DED-4142-9B06-6638CCE4C609@cisco.com> <0b68e10b2a1c69483aca0a58cdac9aea@it.uc3m.es> <25ecebd4d02476187199445d63130075@it.uc3m.es><4629B719.7070407@piuha.net><3B65F69D-979B-4AE2-86DD-78B1BF2475AB@cisco.com><462C35F1.8090402@piuha.net> From: "Templin, Fred L" To: "Dino Farinacci" , "Jari Arkko" X-OriginalArrivalTime: 23 Apr 2007 15:19:44.0376 (UTC) FILETIME=[D2678780:01C785BA] X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Tony Li , 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 Don't know if this will be of interest, but I am planning to put out an update to IPvLX RSN and that should give new details for at least one mapping scheme proposal. Fred fred.l.templin@boeing.com =20 > -----Original Message----- > From: Dino Farinacci [mailto:dino@cisco.com]=20 > Sent: Sunday, April 22, 2007 9:49 PM > To: Jari Arkko > Cc: Tony Li; ram@iab.org > Subject: Re: ID/loc mapping distribution protocol (was Re:=20 > [RAM] IncrementalDeployment of LISP >=20 > > Right. And I don't think we should wait, either -- if you have a =20 > > mapping > > system please write it up in a draft & implement & test. We=20 > need that > > level of concreteness to understand whether our ideas really work > > or not. I was merely suggesting that we do not use a lot of energy > > on the list to debate whether the protocol is new or reused. There > > are other, more worthy topics to be debated... >=20 > Okay, sure. >=20 > Dino >=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 Wed Apr 25 06:47:10 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgf1e-0001eD-Pg; Wed, 25 Apr 2007 06:47:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hgf1d-0001dr-Vo for ram@iab.org; Wed, 25 Apr 2007 06:47:05 -0400 Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hgf1d-0003rj-GM for ram@iab.org; Wed, 25 Apr 2007 06:47:05 -0400 Received: from p130.piuha.net (localhost [127.0.0.1]) by p130.piuha.net (Postfix) with ESMTP id A8A5119868C; Wed, 25 Apr 2007 13:47:04 +0300 (EEST) Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 6CD2B19868B; Wed, 25 Apr 2007 13:47:04 +0300 (EEST) Message-ID: <462F31A9.3050408@piuha.net> Date: Wed, 25 Apr 2007 13:47:05 +0300 From: Jari Arkko User-Agent: Thunderbird 1.5.0.10 (X11/20070306) MIME-Version: 1.0 To: ram@iab.org 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: 50a516d93fd399dc60588708fd9a3002 Cc: Internet Area Subject: [RAM] Identifier-locator separation work and routing scalability X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Jari Arkko , ram@iab.org List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org At the last IETF meeting in Prague, we spent our int-area open meeting time presenting on and providing open mic discussion for identifier/locater split solution design in general, as well as in specific reference to recent energy from the service provider community looking for fundamental routing scalability improvements. Work on the routing and addressing problem is happening in several parallel efforts, including implementation improvements by vendors, review of operational practices, modest improvements to the BGP protocol, and more fundamental architectural changes either through new types of routing architectures or identifier-locator separation. Some of these activities fall clearly on one forum, whereas in others we've had more confusion where the work belongs. In particular, there is a lot of current identifier-locator and locator-locator separation effort in the Internet area, we held int-area, rtg-area, and plenary meetings in Prague, and the Routing Research Group (RRG) is now looking at new routing and addressing architectures. To avoid duplication of effort, the Internet ADs would like to recommend that for solving the routing scalability problem, the research and exploration phase needed before standardization work should continue in the RRG for now rather than in the IETF. Current id/loc and loc/loc work for mobility and multihoming in the int-area (such as HIP) will continue unabated, and we encourage participation in the discussion sponsored by the IAB and IRTF. When the RRG reaches a point where part or all of its effort requires engineering work, we are eager to create a new or recharter an existing working group for this via the normal IETF process. We will send another note later on how to best start such work in the IETF. Work does not have to come from the RRG alone, but we are not going to actively cultivate work in the int-area on this at this time. Given this, we will not be hosting an Interim meeting on this topic before Chicago. The RRG and IAB still may on their own accord, but the main activity that we are currently aware of is the RRG meeting in Chicago (Friday, July 27th). Jari Arkko Mark Townsley _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Wed Apr 25 09:10:59 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghGh-0004pB-UL; Wed, 25 Apr 2007 09:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HghGg-0004p2-LA for ram@iab.org; Wed, 25 Apr 2007 09:10:46 -0400 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HghGg-0002gr-69 for ram@iab.org; Wed, 25 Apr 2007 09:10:46 -0400 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JH21XO00.J3E; Wed, 25 Apr 2007 15:10:36 +0200 In-Reply-To: <462F3CEA.9050709@info.ucl.ac.be> X-Priority: 1 (High) To: pfr@info.ucl.ac.be Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Wed, 25 Apr 2007 15:10:34 +0200 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 25/04/2007 15:10:33, Serialize complete at 25/04/2007 15:10:33 X-Spam-Score: 0.4 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 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="===============1813790278==" Errors-To: ram-bounces@iab.org This is a multipart message in MIME format. --===============1813790278== Content-Type: multipart/alternative; boundary="=_alternative 00486100C12572C8_=" This is a multipart message in MIME format. --=_alternative 00486100C12572C8_= Content-Type: text/plain; charset="US-ASCII" Pierre, See my comments below. Pierre Francois wrote on 25/04/2007 13:35:06: > > Juan-Jose, > > A simple question for you : > > Where does the growth happen with the years ? > I.e., how does this transit ratio evolve during the life of the internet ? > + Same question with finer granularity than just transit vs. leaf., if > possible. > > I would like to know wether we're roughly just getting new leaves or > close-to-be leaves, or if the growth is more homogeneous > in the hierarchy. When trying to find out the fraction of transit AS-es I just used the RIS Statistics Report provided by RIPE. I didn't use any script at all. I simply made a number of calculations using the last statistics reports and found 1/6 as the approximate value. I don't understand why this value differs from the one calculated by Ricardo and Simon. Any clue?. Therefore I cannot answer your questions properly. I think it would be very interesting if we could have a figure showing the evolution of this fraction. And I also suggested that it is probable that its value would decrease because of the number of companies requesting a public AS number to get multihomed. This is just a personal conjecture that I would like to see contrasted with the real Internet. Regards, Juanjo --=_alternative 00486100C12572C8_= Content-Type: text/html; charset="US-ASCII"
Pierre,

See my comments below.

Pierre Francois <pfr@info.ucl.ac.be> wrote on 25/04/2007 13:35:06:
>
> Juan-Jose,
>
> A simple question for you :
>
> Where does the growth happen with the years ?
> I.e., how does this transit ratio evolve during the life of the internet ?
> + Same question with finer granularity than just transit vs. leaf.,  if
> possible.
>
> I would like to know wether we're roughly just getting new leaves or
> close-to-be leaves, or if the growth is more homogeneous
> in the hierarchy.
When trying to find out the fraction of transit AS-es I just
used the RIS Statistics Report provided by RIPE. I didn't
use any script at all. I simply made a number of calculations
using the last statistics reports and found 1/6 as the
approximate value. I don't understand why this value differs
from the one calculated by Ricardo and Simon. Any clue?.

Therefore I cannot answer your questions properly. I think
it would be very interesting if we could have a figure showing
the evolution of this fraction. And I also suggested that it
is probable that its value would decrease because of the
number of companies requesting a public AS number to get
multihomed. This is just a personal conjecture that I would
like to see contrasted with the real Internet.

Regards,
Juanjo
--=_alternative 00486100C12572C8_=-- --===============1813790278== 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 --===============1813790278==-- From ram-bounces@iab.org Wed Apr 25 09:32:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghbo-0007pZ-36; Wed, 25 Apr 2007 09:32:36 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hghbm-0007pT-Ry for ram@iab.org; Wed, 25 Apr 2007 09:32:34 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hghbm-0000p3-De for ram@iab.org; Wed, 25 Apr 2007 09:32:34 -0400 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 6535070; Wed, 25 Apr 2007 09:32:34 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 1 (High) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <32E1430B-7D36-4EE3-B11B-C2BF1AD93921@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] Date: Wed, 25 Apr 2007 09:32:32 -0400 To: JUAN-JOSE.ADAN@giss.seg-social.es X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: 16c9da4896bf5539ae3547c6c25f06a0 Cc: ram@iab.org, pfr@info.ucl.ac.be 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 Hello; On Apr 25, 2007, at 9:10 AM, JUAN-JOSE.ADAN@giss.seg-social.es wrote: > > Pierre, > > See my comments below. > > Pierre Francois wrote on 25/04/2007 13:35:06: > > > > Juan-Jose, > > > > A simple question for you : > > > > Where does the growth happen with the years ? > > I.e., how does this transit ratio evolve during the life of the > internet ? > > + Same question with finer granularity than just transit vs. > leaf., if > > possible. > > > > I would like to know wether we're roughly just getting new leaves or > > close-to-be leaves, or if the growth is more homogeneous > > in the hierarchy. > > When trying to find out the fraction of transit AS-es I just > used the RIS Statistics Report provided by RIPE. I didn't > use any script at all. I simply made a number of calculations > using the last statistics reports and found 1/6 as the > approximate value. I don't understand why this value differs > from the one calculated by Ricardo and Simon. Any clue?. > I do not know, but if I had to guess I would guess this is the effect of route aggregation, which will tend to "bury" leaf asn's. I get 12% (1/6 is 16.6%) from my BGP data, so this is even less. The following histogram for 6:00 AM today might be interesting. All of this data is available going back to 2001; what exactly do you think it would useful to plot ? Regards Marshall Histogram of the number of AS Supported Out of 24857 (In my terminology, an ASN "supports" every ASN that can be seen in transit through it; so the ASN with support = 1 are leaf ASNs.) Number ASN Supporting 1 ASN = 21989 or 88.462 % Number ASN Supporting 2 ASN = 1210 or 4.868 % Number ASN Supporting 3 ASN = 431 or 1.734 % Number ASN Supporting 4 ASN = 234 or 0.941 % Number ASN Supporting 5 ASN = 161 or 0.648 % Number ASN Supporting 6 ASN = 108 or 0.434 % Number ASN Supporting 7 ASN = 79 or 0.318 % Number ASN Supporting 8 ASN = 66 or 0.266 % Number ASN Supporting 9 ASN = 53 or 0.213 % Number ASN Supporting 10 ASN = 32 or 0.129 % Number ASN Supporting 11 ASN = 38 or 0.153 % Number ASN Supporting 12 ASN = 32 or 0.129 % Number ASN Supporting 13 ASN = 23 or 0.093 % Number ASN Supporting 14 ASN = 27 or 0.109 % Number ASN Supporting 15 ASN = 17 or 0.068 % Number ASN Supporting 16 ASN = 24 or 0.097 % Number ASN Supporting 17 ASN = 14 or 0.056 % Number ASN Supporting 18 ASN = 15 or 0.060 % Number ASN Supporting 19 ASN = 9 or 0.036 % Number ASN Supporting 20 ASN = 10 or 0.040 % Number ASN Supporting 21 ASN = 15 or 0.060 % Number ASN Supporting 22 ASN = 7 or 0.028 % Number ASN Supporting 23 ASN = 10 or 0.040 % Number ASN Supporting 24 ASN = 7 or 0.028 % Number ASN Supporting 25 ASN = 8 or 0.032 % Number ASN Supporting 26 ASN = 3 or 0.012 % Number ASN Supporting 27 ASN = 9 or 0.036 % Number ASN Supporting 28 ASN = 4 or 0.016 % Number ASN Supporting 29 ASN = 7 or 0.028 % Number ASN Supporting 30 ASN = 9 or 0.036 % Number ASN Supporting 31 ASN = 6 or 0.024 % Number ASN Supporting 32 ASN = 8 or 0.032 % Number ASN Supporting 33 ASN = 7 or 0.028 % Number ASN Supporting 34 ASN = 5 or 0.020 % Number ASN Supporting 35 ASN = 3 or 0.012 % Number ASN Supporting 36 ASN = 5 or 0.020 % Number ASN Supporting 37 ASN = 7 or 0.028 % Number ASN Supporting 38 ASN = 3 or 0.012 % Number ASN Supporting 40 ASN = 6 or 0.024 % Number ASN Supporting 41 ASN = 5 or 0.020 % Number ASN Supporting 42 ASN = 2 or 0.008 % Number ASN Supporting 43 ASN = 2 or 0.008 % Number ASN Supporting 44 ASN = 2 or 0.008 % Number ASN Supporting 45 ASN = 3 or 0.012 % Number ASN Supporting 46 ASN = 2 or 0.008 % Number ASN Supporting 47 ASN = 1 or 0.004 % Number ASN Supporting 48 ASN = 6 or 0.024 % Number ASN Supporting 49 ASN = 6 or 0.024 % Number ASN Supporting 51 ASN = 2 or 0.008 % Number ASN Supporting 52 ASN = 1 or 0.004 % Number ASN Supporting 53 ASN = 1 or 0.004 % Number ASN Supporting 54 ASN = 2 or 0.008 % Number ASN Supporting 55 ASN = 1 or 0.004 % Number ASN Supporting 57 ASN = 3 or 0.012 % Number ASN Supporting 58 ASN = 2 or 0.008 % Number ASN Supporting 59 ASN = 2 or 0.008 % Number ASN Supporting 61 ASN = 1 or 0.004 % Number ASN Supporting 64 ASN = 1 or 0.004 % Number ASN Supporting 65 ASN = 1 or 0.004 % Number ASN Supporting 66 ASN = 1 or 0.004 % Number ASN Supporting 67 ASN = 3 or 0.012 % Number ASN Supporting 68 ASN = 1 or 0.004 % Number ASN Supporting 71 ASN = 2 or 0.008 % Number ASN Supporting 72 ASN = 1 or 0.004 % Number ASN Supporting 73 ASN = 2 or 0.008 % Number ASN Supporting 75 ASN = 2 or 0.008 % Number ASN Supporting 79 ASN = 1 or 0.004 % Number ASN Supporting 81 ASN = 1 or 0.004 % Number ASN Supporting 83 ASN = 1 or 0.004 % Number ASN Supporting 85 ASN = 1 or 0.004 % Number ASN Supporting 87 ASN = 1 or 0.004 % Number ASN Supporting 89 ASN = 1 or 0.004 % Number ASN Supporting 90 ASN = 1 or 0.004 % Number ASN Supporting 92 ASN = 1 or 0.004 % Number ASN Supporting 94 ASN = 1 or 0.004 % Number ASN Supporting 98 ASN = 2 or 0.008 % Number ASN Supporting 99 ASN = 1 or 0.004 % Number ASN Supporting 101 ASN = 1 or 0.004 % Number ASN Supporting 102 ASN = 1 or 0.004 % Number ASN Supporting 103 ASN = 1 or 0.004 % Number ASN Supporting 105 ASN = 1 or 0.004 % Number ASN Supporting 107 ASN = 1 or 0.004 % Number ASN Supporting 110 ASN = 1 or 0.004 % Number ASN Supporting 114 ASN = 1 or 0.004 % Number ASN Supporting 118 ASN = 1 or 0.004 % Number ASN Supporting 131 ASN = 1 or 0.004 % Number ASN Supporting 132 ASN = 1 or 0.004 % Number ASN Supporting 133 ASN = 1 or 0.004 % Number ASN Supporting 134 ASN = 1 or 0.004 % Number ASN Supporting 142 ASN = 1 or 0.004 % Number ASN Supporting 154 ASN = 1 or 0.004 % Number ASN Supporting 155 ASN = 1 or 0.004 % Number ASN Supporting 158 ASN = 2 or 0.008 % Number ASN Supporting 160 ASN = 1 or 0.004 % Number ASN Supporting 163 ASN = 1 or 0.004 % Number ASN Supporting 169 ASN = 1 or 0.004 % Number ASN Supporting 170 ASN = 1 or 0.004 % Number ASN Supporting 176 ASN = 1 or 0.004 % Number ASN Supporting 186 ASN = 1 or 0.004 % Number ASN Supporting 189 ASN = 1 or 0.004 % Number ASN Supporting 197 ASN = 1 or 0.004 % Number ASN Supporting 201 ASN = 1 or 0.004 % Number ASN Supporting 204 ASN = 1 or 0.004 % Number ASN Supporting 216 ASN = 1 or 0.004 % Number ASN Supporting 219 ASN = 1 or 0.004 % Number ASN Supporting 232 ASN = 1 or 0.004 % Number ASN Supporting 237 ASN = 1 or 0.004 % Number ASN Supporting 239 ASN = 1 or 0.004 % Number ASN Supporting 241 ASN = 1 or 0.004 % Number ASN Supporting 253 ASN = 1 or 0.004 % Number ASN Supporting 254 ASN = 1 or 0.004 % Number ASN Supporting 267 ASN = 1 or 0.004 % Number ASN Supporting 273 ASN = 1 or 0.004 % Number ASN Supporting 297 ASN = 1 or 0.004 % Number ASN Supporting 300 ASN = 2 or 0.008 % Number ASN Supporting 315 ASN = 1 or 0.004 % Number ASN Supporting 322 ASN = 1 or 0.004 % Number ASN Supporting 349 ASN = 1 or 0.004 % Number ASN Supporting 389 ASN = 1 or 0.004 % Number ASN Supporting 413 ASN = 1 or 0.004 % Number ASN Supporting 423 ASN = 1 or 0.004 % Number ASN Supporting 425 ASN = 1 or 0.004 % Number ASN Supporting 440 ASN = 1 or 0.004 % Number ASN Supporting 584 ASN = 1 or 0.004 % Number ASN Supporting 834 ASN = 1 or 0.004 % Number ASN Supporting 888 ASN = 1 or 0.004 % Number ASN Supporting 945 ASN = 1 or 0.004 % Number ASN Supporting 947 ASN = 1 or 0.004 % Number ASN Supporting 1054 ASN = 1 or 0.004 % Number ASN Supporting 1896 ASN = 1 or 0.004 % > Therefore I cannot answer your questions properly. I think > it would be very interesting if we could have a figure showing > the evolution of this fraction. And I also suggested that it > is probable that its value would decrease because of the > number of companies requesting a public AS number to get > multihomed. This is just a personal conjecture that I would > like to see contrasted with the real Internet. > > Regards, > Juanjo > _______________________________________________ > 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 Wed Apr 25 11:13:16 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgjB9-0006t2-71; Wed, 25 Apr 2007 11:13:11 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HgiTV-00005Z-DU for ram@iab.org; Wed, 25 Apr 2007 10:28:05 -0400 Received: from smtp-1.dynsipr.ucl.ac.be ([130.104.4.1] helo=smtp1.sgsi.ucl.ac.be) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HgiTU-0004iw-1J for ram@iab.org; Wed, 25 Apr 2007 10:28:05 -0400 Received: from smtp1.sgsi.ucl.ac.be (localhost.localdomain [127.0.0.1]) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP id 258A02C482; Wed, 25 Apr 2007 16:27:59 +0200 (CEST) Received: from [130.104.229.117] (unknown [130.104.229.117]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: pifrancois@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTP; Wed, 25 Apr 2007 16:27:59 +0200 (CEST) Message-ID: <462F656B.9000302@info.ucl.ac.be> Date: Wed, 25 Apr 2007 16:27:55 +0200 From: Pierre Francois User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Marshall Eubanks Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] References: <32E1430B-7D36-4EE3-B11B-C2BF1AD93921@multicasttech.com> In-Reply-To: <32E1430B-7D36-4EE3-B11B-C2BF1AD93921@multicasttech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-AV-Checked: ClamAV using ClamSMTP X-SGSI-MailScanner: Found to be clean X-SGSI-SpamCheck: X-SGSI-From: pfr@info.ucl.ac.be X-SGSI-Spam-Status: No X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-Mailman-Approved-At: Wed, 25 Apr 2007 11:13:09 -0400 Cc: JUAN-JOSE.ADAN@giss.seg-social.es, ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: pfr@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 Marshall Eubanks wrote: > I do not know, but if I had to guess I would guess this is the effect > of route aggregation, which will tend > to "bury" leaf asn's. If the question is destined to me : I would "cluster" the histogramm you provide : group 1 : Number of ASN supporting 1 ASN group 2 : Number of ASN supporting 2 ASN group 3 : Number of ASN supporting 3 ASN group 4 : Number of ASN supporting ]3,10] ASN, group 5 : Number of ASN supporting ]10, 100] ASN, group 6 : Number of ASN supporting > 100 ASN, Then look at how these values evolve since 2001. I have no clue on which clustering would reveal interesting trends, but this could be worth the investigation. (would have been good to have it just a bit earlier than 2001 ;-) ) btw, Sorry to have messed the thread Pierre _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Thu Apr 26 07:20:37 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh21Z-0004eL-8B; Thu, 26 Apr 2007 07:20:33 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh21X-0004eD-CY for ram@iab.org; Thu, 26 Apr 2007 07:20:31 -0400 Received: from giss7a.seg-social.es ([194.179.55.135] helo=smtp.seg-social.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh21V-00068j-Pc for ram@iab.org; Thu, 26 Apr 2007 07:20:31 -0400 Received: from gwsalida1.correo.portal.ss ([10.99.1.224]) by smtp.seg-social.es (Netscape Messaging Server 4.15) with ESMTP id JH3RI201.K1P; Thu, 26 Apr 2007 13:20:26 +0200 X-Priority: 1 (High) To: Marshall Eubanks , pfr@info.ucl.ac.be Subject: Fw: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.5 November 30, 2005 Message-ID: From: JUAN-JOSE.ADAN@giss.seg-social.es Date: Thu, 26 Apr 2007 13:20:23 +0200 X-MIMETrack: Serialize by Router on GWSALIDA1/SRV/SEG-SOCIAL(Release 6.5.5|November 30, 2005) at 26/04/2007 13:20:23, Serialize complete at 26/04/2007 13:20:23 X-Spam-Score: 0.4 (/) X-Scan-Signature: f2984bf50fb52a9e56055f779793d783 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="===============1265679013==" Errors-To: ram-bounces@iab.org This is a multipart message in MIME format. --===============1265679013== Content-Type: multipart/alternative; boundary="=_alternative 003E4B1BC12572C9_=" This is a multipart message in MIME format. --=_alternative 003E4B1BC12572C9_= Content-Type: text/plain; charset="US-ASCII" Marshall and Pierre, Thank you for your mails. Please see below. Pierre Francois wrote on 25/04/2007 16:27:55: > Marshall Eubanks wrote: > > I do not know, but if I had to guess I would guess this is the effect > > of route aggregation, which will tend > > to "bury" leaf asn's. > If the question is destined to me : > > I would "cluster" the histogramm you provide : > group 1 : Number of ASN supporting 1 ASN > group 2 : Number of ASN supporting 2 ASN > group 3 : Number of ASN supporting 3 ASN > group 4 : Number of ASN supporting ]3,10] ASN, > group 5 : Number of ASN supporting ]10, 100] ASN, > group 6 : Number of ASN supporting > 100 ASN, > > Then look at how these values evolve since 2001. I have no clue on which > clustering would reveal interesting trends, but this could > be worth the investigation. (would have been good to have it just a bit > earlier than 2001 ;-) ) The proposal made by Pierre is also fine to me. Another interesting table would be the number and percentage of transit AS-es having just 2 upstream transit providers, or 3, or 4, etc. > > Histogram of the number of AS Supported Out of 24857 > > > > Number ASN Supporting 1 ASN = 21989 or 88.462 % > > The results of your data is very important because it confirms again the small fraction of transit AS-es in the Internet: we have around 2868 transit AS-es (24857-21989). I think this supports the use of a "locator prefix" per transit AS as a method to reduce the RIB as I proposed in the TIDR draft. In its simplest form, where each transit AS announces only one /32 "locator prefix" to receive tunneled traffic for its leaf customers, we would have a RIB containing 2868 prefixes. This "locator prefix" could be thought of as the "IP address" of the autonomous system, and it is where the multipoint TIDR tunnel ends. Don't forget that a transit AS is a customer of itself in the sense that it will use the same "locator prefix" to receive tunneled traffic for the prefixes that it is currently originating ("identifier prefixes"). Moving further, if each transit AS announces for example 100 /32 "locator prefixes" so that each of these corresponds to a specific entry point from the interdomain infrastructure (i.e. interfaces not facing leaf customers) we will have a RIB containing 286800 prefixes, which is a little bigger than current RIB. But for regional transit AS-es is quite common to have just a small number (2, 3, 4, ...) of upstream providers. The evolution of the fraction of transit AS-es could also support my proposal as follows: if this fraction keeps decreasing over time the benefit of holding in the RIB only the "locator prefixes" will be more clearly seen (don't let leaf AS-es to influence on the RIB because they are not within the INTER-domain infrastructure), Prefixes of the leaf AS-es will not be in the RIB but in the TIB. Any comments?. Am I too wrong?. Regards, Juanjo --=_alternative 003E4B1BC12572C9_= Content-Type: text/html; charset="US-ASCII"
Marshall and Pierre,

Thank you for your mails. Please see below.

Pierre Francois <pfr@info.ucl.ac.be> wrote on 25/04/2007 16:27:55:
> Marshall Eubanks wrote:
> > I do not know, but if I had to guess I would guess this is the effect
> > of route aggregation, which will tend
> > to "bury" leaf asn's.
> If the question is destined to me :
>
> I would "cluster" the histogramm you provide :
> group 1 : Number of ASN supporting 1 ASN
> group 2 : Number of ASN supporting 2 ASN
> group 3 : Number of ASN supporting 3 ASN
> group 4 : Number of ASN supporting ]3,10] ASN,
> group 5 : Number of ASN supporting ]10, 100] ASN,
> group 6 : Number of ASN supporting > 100  ASN,
>
> Then look at how these values evolve since 2001. I have no clue on which
> clustering would reveal interesting trends, but this could
> be worth the investigation. (would have been good to have it just a bit
> earlier than 2001 ;-)  )
The proposal made by Pierre is also fine to me. Another
interesting table would be the number and percentage of
transit AS-es having just 2 upstream transit providers,
or 3, or 4, etc.

> > Histogram of the number of AS Supported Out of  24857
> >
> > Number ASN Supporting      1 ASN =  21989  or 88.462 %
> >

The results of your data is very important because it
confirms again the small fraction of transit AS-es in the
Internet: we have around 2868 transit AS-es (24857-21989).

I think this supports the use of a "locator prefix" per
transit AS as a method to reduce the RIB as I proposed
in the TIDR draft.

In its simplest form, where each transit AS announces only
one /32 "locator prefix" to receive tunneled traffic for its
leaf customers, we would have a RIB containing 2868 prefixes.
This "locator prefix" could be thought of as the "IP address"
of the autonomous system, and it is where the multipoint
TIDR tunnel ends.

Don't forget that a transit AS is a customer of itself
in the sense that it will use the same "locator prefix"
to receive tunneled traffic for the prefixes that it is
currently originating ("identifier prefixes").

Moving further, if each transit AS announces for example
100 /32 "locator prefixes" so that each of these corresponds
to a specific entry point from the interdomain
infrastructure (i.e. interfaces not facing leaf customers)
we will have a RIB containing 286800 prefixes, which is
a little bigger than current RIB. But for regional
transit AS-es is quite common to have just a small number
(2, 3, 4, ...) of upstream providers.

The evolution of the fraction of transit AS-es could also
support my proposal as follows: if this fraction keeps
decreasing over time the benefit of holding in the RIB
only the "locator prefixes" will be more clearly seen
(don't let leaf AS-es to influence on the RIB because
they are not within the INTER-domain infrastructure),

Prefixes of the leaf AS-es will not be in the RIB but
in the TIB.


Any comments?. Am I too wrong?.

Regards,
Juanjo

--=_alternative 003E4B1BC12572C9_=-- --===============1265679013== 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 --===============1265679013==-- From ram-bounces@iab.org Thu Apr 26 08:31:45 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh38M-0001DZ-BT; Thu, 26 Apr 2007 08:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hh38K-0001DR-BX for ram@iab.org; Thu, 26 Apr 2007 08:31:36 -0400 Received: from lennon.multicasttech.com ([63.105.122.7] helo=multicasttech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hh38K-0001x8-3g for ram@iab.org; Thu, 26 Apr 2007 08:31:36 -0400 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 6538666; Thu, 26 Apr 2007 08:31:35 -0400 In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v752.3) X-Priority: 1 (High) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <72707A4A-8FA9-4AF4-858C-76E64F42273F@multicasttech.com> Content-Transfer-Encoding: 7bit From: Marshall Eubanks Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using the IDENTIFIERS attribute] Date: Thu, 26 Apr 2007 08:31:32 -0400 To: JUAN-JOSE.ADAN@giss.seg-social.es X-Mailer: Apple Mail (2.752.3) X-Spam-Score: 0.1 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e 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 Apr 26, 2007, at 7:20 AM, JUAN-JOSE.ADAN@giss.seg-social.es wrote: > > Marshall and Pierre, > > Thank you for your mails. Please see below. > > Pierre Francois wrote on 25/04/2007 16:27:55: > > Marshall Eubanks wrote: > > > I do not know, but if I had to guess I would guess this is the > effect > > > of route aggregation, which will tend > > > to "bury" leaf asn's. > > If the question is destined to me : > > > > I would "cluster" the histogramm you provide : > > group 1 : Number of ASN supporting 1 ASN > > group 2 : Number of ASN supporting 2 ASN > > group 3 : Number of ASN supporting 3 ASN > > group 4 : Number of ASN supporting ]3,10] ASN, > > group 5 : Number of ASN supporting ]10, 100] ASN, > > group 6 : Number of ASN supporting > 100 ASN, > > > > Then look at how these values evolve since 2001. I have no clue > on which > > clustering would reveal interesting trends, but this could > > be worth the investigation. (would have been good to have it just > a bit > > earlier than 2001 ;-) ) > > The proposal made by Pierre is also fine to me. Another > interesting table would be the number and percentage of > transit AS-es having just 2 upstream transit providers, > or 3, or 4, etc. > > > > Histogram of the number of AS Supported Out of 24857 > > > > > > Number ASN Supporting 1 ASN = 21989 or 88.462 % > > > > > The results of your data is very important because it > confirms again the small fraction of transit AS-es in the > Internet: we have around 2868 transit AS-es (24857-21989). > Hello; I would like to understand why, when there is general agreement as to the total number of ASNs, the proportion of transit vs leaf ASN's is so different. (if it is due to aggregation, I would expect the total numbers to change a fair amount as well.) I am looking into my code; can anyone see an problem with the way I have defined "support" ? Regards Marshall > I think this supports the use of a "locator prefix" per > transit AS as a method to reduce the RIB as I proposed > in the TIDR draft. > > In its simplest form, where each transit AS announces only > one /32 "locator prefix" to receive tunneled traffic for its > leaf customers, we would have a RIB containing 2868 prefixes. > This "locator prefix" could be thought of as the "IP address" > of the autonomous system, and it is where the multipoint > TIDR tunnel ends. > > Don't forget that a transit AS is a customer of itself > in the sense that it will use the same "locator prefix" > to receive tunneled traffic for the prefixes that it is > currently originating ("identifier prefixes"). > > Moving further, if each transit AS announces for example > 100 /32 "locator prefixes" so that each of these corresponds > to a specific entry point from the interdomain > infrastructure (i.e. interfaces not facing leaf customers) > we will have a RIB containing 286800 prefixes, which is > a little bigger than current RIB. But for regional > transit AS-es is quite common to have just a small number > (2, 3, 4, ...) of upstream providers. > > The evolution of the fraction of transit AS-es could also > support my proposal as follows: if this fraction keeps > decreasing over time the benefit of holding in the RIB > only the "locator prefixes" will be more clearly seen > (don't let leaf AS-es to influence on the RIB because > they are not within the INTER-domain infrastructure), > > Prefixes of the leaf AS-es will not be in the RIB but > in the TIB. > > > Any comments?. Am I too wrong?. > > Regards, > Juanjo > _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram From ram-bounces@iab.org Fri Apr 27 13:27:35 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUE7-0004p2-ER; Fri, 27 Apr 2007 13:27:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HhUE6-0004np-L5 for ram@iab.org; Fri, 27 Apr 2007 13:27:22 -0400 Received: from ranger.systems.pipex.net ([62.241.162.32]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HhUE6-0008Ic-64 for ram@iab.org; Fri, 27 Apr 2007 13:27:22 -0400 Received: from pc6 (1Cust231.tnt13.lnd4.gbr.da.uu.net [62.188.142.231]) by ranger.systems.pipex.net (Postfix) with SMTP id 53FECE0004C7; Fri, 27 Apr 2007 18:27:19 +0100 (BST) Message-ID: <05cf01c788e8$7972b7e0$0601a8c0@pc6> From: "tom.petch" To: "Marshall Eubanks" References: <72707A4A-8FA9-4AF4-858C-76E64F42273F@multicasttech.com> Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using theIDENTIFIERS attribute] Date: Fri, 27 Apr 2007 18:24:01 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 0.0 (/) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: ram@iab.org X-BeenThere: ram@iab.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "tom.petch" List-Id: Routing and Addressing Mailing List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: ram-bounces@iab.org I too am curious (and do think these metrics should inform our choices). When there are two different results, then either the data is different and/or the algorithm is different. Obvious I know but it does provide the way to resolve any such problem. Also, it tells me that I cannot readily take it further because I do not know the algorithm in use and do not have a clear view of the underlying data. The result I am used to is the one posted to nanog, eg Total ASes present in the Internet Routing Table: 24788 Origin-only ASes present in the Internet Routing Table: 21588 Transit ASes present in the Internet Routing Table: 3200 Transit-only ASes present in the Internet Routing Table: 71 Were I to produce such an analysis, I would have to define an Origin-only AS. Is it one that never produces a eBGP IPv4 UPDATE with any other ASN in it than its own? What if it prepends its own twice? What if private ASN leak through? And if an update does contain a foreign ASN, what if such an UPDATE never gets into a FIB because there is always a 'better' one (which is not the same thing as aggregation)? This last makes the analysis dependent on the Internet topology. I note that the data cited above comes from an APNIC router in Japan and is based on 'BGP routing table entries examined:' which I take to be IPv4 FIB entries. I also imagine that a router in Japan might well see UPDATEs coming via fewer ASN than a router in, say, the historic center of the Internet. 1/6 v 1/3? Perhaps. Tom Petch ----- Original Message ----- From: "Marshall Eubanks" To: Cc: Sent: Thursday, April 26, 2007 2:31 PM Subject: Re: Fraction of transit ASes going down? [Re: [RAM] TIDR using theIDENTIFIERS attribute] > > On Apr 26, 2007, at 7:20 AM, JUAN-JOSE.ADAN@giss.seg-social.es wrote: > > I would like to understand why, when there is general agreement as to > the total number > of ASNs, the proportion of transit vs leaf ASN's is so different. (if > it is due to aggregation, > I would expect the total numbers to change a fair amount as well.) > > I am looking into my code; can anyone see an problem with the way I > have defined > "support" ? > > Regards > Marshall > > > I think this supports the use of a "locator prefix" per > > transit AS as a method to reduce the RIB as I proposed > > in the TIDR draft. > > > > In its simplest form, where each transit AS announces only > > one /32 "locator prefix" to receive tunneled traffic for its > > leaf customers, we would have a RIB containing 2868 prefixes. > > This "locator prefix" could be thought of as the "IP address" > > of the autonomous system, and it is where the multipoint > > TIDR tunnel ends. > > > > Don't forget that a transit AS is a customer of itself > > in the sense that it will use the same "locator prefix" > > to receive tunneled traffic for the prefixes that it is > > currently originating ("identifier prefixes"). > > > > Moving further, if each transit AS announces for example > > 100 /32 "locator prefixes" so that each of these corresponds > > to a specific entry point from the interdomain > > infrastructure (i.e. interfaces not facing leaf customers) > > we will have a RIB containing 286800 prefixes, which is > > a little bigger than current RIB. But for regional > > transit AS-es is quite common to have just a small number > > (2, 3, 4, ...) of upstream providers. > > > > The evolution of the fraction of transit AS-es could also > > support my proposal as follows: if this fraction keeps > > decreasing over time the benefit of holding in the RIB > > only the "locator prefixes" will be more clearly seen > > (don't let leaf AS-es to influence on the RIB because > > they are not within the INTER-domain infrastructure), > > > > Prefixes of the leaf AS-es will not be in the RIB but > > in the TIB. > > > > > > Any comments?. Am I too wrong?. > > > > Regards, > > Juanjo > > > > > _______________________________________________ > 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