[RAM] Preliminary thoughts on LISP 1.5
Vince Fuller <vaf@cisco.com> Wed, 20 June 2007 18:37 UTC
Return-path: <ram-bounces@iab.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1I153G-0001IR-F6; Wed, 20 Jun 2007 14:37:10 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1I153F-00014d-3f for ram@iab.org; Wed, 20 Jun 2007 14:37:09 -0400
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1I153E-0001Ut-Hr for ram@iab.org; Wed, 20 Jun 2007 14:37:09 -0400
Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 20 Jun 2007 11:37:03 -0700
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgAAAG8QeUarR7PEh2dsb2JhbACPHgEBAQgOLA
X-IronPort-AV: i="4.16,443,1175497200"; d="scan'208"; a="163557324:sNHT154228806"
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 l5KIb3hu028147 for <ram@iab.org>; Wed, 20 Jun 2007 11:37:03 -0700
Received: from vaf-lnx1.cisco.com (vaf-lnx1.cisco.com [171.71.118.48]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l5KIb0aI021558 for <ram@iab.org>; Wed, 20 Jun 2007 18:37:03 GMT
Received: by vaf-lnx1.cisco.com (Postfix, from userid 113818) id 9E4B13D80AF; Wed, 20 Jun 2007 11:35:47 -0700 (PDT)
Date: Wed, 20 Jun 2007 11:35:47 -0700
From: Vince Fuller <vaf@cisco.com>
To: ram@iab.org
Message-ID: <20070620183547.GA24174@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
User-Agent: Mutt/1.5.13 (2006-08-11)
DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=7115; t=1182364623; x=1183228623; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=vaf@cisco.com; z=From:=20Vince=20Fuller=20<vaf@cisco.com> |Subject:=20Preliminary=20thoughts=20on=20LISP=201.5 |Sender:=20; bh=gAPRjy5VPLm3tIUW4uffr2DKJqRLFA9/fVDiB3UHK7U=; b=kFXRq9Rso7joq9zDyxqr80vfdSvFMEdIejASRKy3LImWBmAO7MthZeuVSVNykHRAZlSwIWLf i2mOngmmCfiYIJ17VvwOtRCB1HAyU3pbuD4kbDXwvcAmFKMQbJJqghaS;
Authentication-Results: sj-dkim-4; header.From=vaf@cisco.com; dkim=pass (sig from cisco.com/sjdkim4002 verified; );
X-Spam-Score: 0.0 (/)
X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab
Subject: [RAM] Preliminary thoughts on LISP 1.5
X-BeenThere: ram@iab.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Routing and Addressing Mailing List <ram.iab.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/ram>
List-Post: <mailto:ram@iab.org>
List-Help: <mailto:ram-request@iab.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ram>, <mailto:ram-request@iab.org?subject=subscribe>
Errors-To: ram-bounces@iab.org
Since there seems to be some ongoing discussion of LISP and whether or not it is incrementally deployable, I thought I'd share the following message which I wrote to a smaller discussion group about two months ago; it sketches out some ideas on how a LISP 1.5 infrastructure might offer a hybrid push/pull model, where highly-aggregated EID prefixes would be "pushed" into a global infrastructure while information about specific destinations of interest to a particular source would be "pulled" in a data-triggered manner using LISP 1.0 protocol machinery. The LISP authors plan to write-up a more complete Internet Draft describing this approach but here are some conceptual ideas. --Vince -------------------- Date: Wed, 4 Apr 2007 09:54:41 -0700 From: Vince Fuller <vaf@cisco.com> Subject: Re: Cache ... > > The thinking here was that the ITR could be co-located with a local > > DNS caching server, and have all of the hosts served by an ITR use > > that same system for DNS lookups. > > That strikes me as a set of extremely unrealistic deployment constraints. Note that this approach is specific to LISP 2 and resresents some thinking on how one would improve EID-to-RLOC setup latency when a mapping doesn't exist for a particular destination. > > 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. > > The most obvious way of reducing the amount of data is by aggregation, of > course. I guess we're looking for alternative methods that don't introduce > enormous amounts of complexity. Well, I hope we're wishing ourselves luck > ;-) > > Certainly if you distribute the data so that it is never all in one place, > you improve the per-box scalability, since each box has less to worry > about. Of course, you might end up needing more boxes. It's never been > clear to me whether a solution which increases the number of boxes rather > than the size of each box would be considered as "solving the problem". > > To first order, I don't think that "pull vs. push" is an important > distinction, since it leaves open the question of where you're pulling from > and whether that is scalable. Also, if you distribute the data, you don't > necessarily need a pull model, you just need to make sure that the data > paths take each packet through a place where the appropriate data can be > found (i.e., if the addressing doesn't follow the topology, make the > topology follow the addressing). This approach is similar to some thoughts that I've had on how an EID-to-RLOC overlay topology might be structured for LISP 1.5. The idea is roughly as follows: 1. Assign EID prefixes according to some hierarchy that bears only rough resemblence to the actual Internet topology. An RIR, exchange-point, or geographic hierarchy is probably good enough here. One that approximately follows DNS delegations would also work. It is probably even possible to construct a hybrid of more than one of these, at a cost of requiring a larger number of "top level" EID prefixes. 2. Build an overlay topology of EID-to-RLOC "LISP translation aggregators" (LTAs) which matches the hierarchy in (1). This topology may contain one or more layers of aggregation, depending on size and scope. LTAs are interconnected by tunnels in a topology that is isomorphic with the prefix assignment hierarchy, with redundancy. 3. For each ETR that holds an authorative EID-to-RLOC mapping for a prefix, configure one or more tunnels to the LTAs which can aggregate that prefix with others at the same point in the assignment hierarchy. The ETR advertises the existance of that EID-to-RLOC mapping using some protocol (BGP, with a separate AFI/SAFI for LISP would work). 4. LTAs aggregate and propagate mappings "upward" toward the root of the assignment hierarchy. 5. For each ITR, confgure one or more tunnels to LTAs. The LTAs advertise the aggregated EID-to-RLOC mappings to the ITR over the tunnel(s). Exactly which LTAs a particular ITR uses depends on the level of detail about the global EID-to-RLOC mapping database that it wishes to have "pushed" to it (again, consider BGP with a separate AFI/SAFI for LISP). The LTAs may advertise (or an ITR may/could/should confgure) a "default" mapping if it wishes to be able to do EID-to-RLOC lookups for any destination in the global routing system. 6. For backward-compatibility with non-LISP-speakers, some set of LTAs can advertise their aggregated EID-to-RLOC mappings into into the existing global routing table. This will draw traffic for those mappings to those LTAs, which serve as "LISP proxies" for non-LISP-capable devices. 7. When an ITR receives a packet for which it has no EID-to-RLOC mapping, it forwards that packet according to the aggregated information it received over its LTA connections. Note that as an implementation detail, this information, along with its cached EID-to-RLOC mappings, can simply be stored in the ITR's FIB, perhaps with some special marking to indicate "EID-to-RLOC mapping" rather than "RLOC forwarding entry". The packet is forwarded through the LTA/overlay topology until it reaches the ETR that originally advertised it; that ETR both forwards the packet to the end system and sends back a specific, cachable EID-to-RLOC mapping to the ITR which received the original packet and encpsulated it in LISP. A few things to note: - This approach does posit the creation of a new, hierarchical LTA infrastructure which will have associated capital and ongoing operational costs. Who would build that infrastructure and how they would recover those costs would depend on where its root achor points are located. Fortunately, there are existing organizations (with existing cost-recovery mechanisms) in place for those achors: IANA and the RIRs, the major global exchange points, etc. - The exact mechanism for data exchange between and throughout the LTA infrastructure is an area that needs a lot more thought, experimentation, etc. One could imagine a number of different approaches: BGP with separate AFI/SAFI (mentioned above), something DNS-like or using DNS protocols (think about zone transfer for "push" and DNS queries for "pull"), DHTs, et alia. - The LTA infrastructure, the ETR-to-LTA, and ITR-to-LTA protocol exchanges are the points at which authentication of the EID-to-RLOC database would most naturally be performed. Adding machinery at those points could address some of the open issues with LISP security. All of this is only partially thought-out at this point (not even half-baked enough to send to the RAM list) and obviously needs more work, perhaps as a successor to the LISP draft that describes the specifics of LISP 1.5. Comments? Thoughts? --Vince _______________________________________________ RAM mailing list RAM@iab.org https://www1.ietf.org/mailman/listinfo/ram
- [RAM] Preliminary thoughts on LISP 1.5 Vince Fuller
- Re: [RAM] Preliminary thoughts on LISP 1.5 Robin Whittle
- Re: [RAM] Preliminary thoughts on LISP 1.5 Michael