[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