Subject: [RAM] Preliminary thoughts on LISP 1.5

From: Vince Fuller <[email-masked]>
Date: Wed, 20 Jun 2007 11:35:47 -0700

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 <[email-masked]>
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
[email-masked]
https://www1.ietf.org/mailman/listinfo/ram

---

From: Robin Whittle <[email-masked]>
Date: Mon, 25 Jun 2007 16:56:08 +1000

Hi Vince,

I have read your email carefully at least three times and I
still don't have a clear understanding of what you are trying to
describe.

Can you or anyone else provide examples, with more concrete
descriptions, diagrams etc. for each point?  For instance, I
couldn't develop a clear example in my mind of any one of your
options for point 1.

I recognise point 6 as being similar to what I thought
distinguished my Ivip idea from LISP.  As far as I knew, apart
from maybe LISP 1.0 (which I understand is a conceptual stage
rather than something which helps reduce the size of the BGP
routing table), for all other LISP variants the (EID) addresses
mapped by the system (to ETR addresses) were not within any
prefix which was advertised by a BGP router.  But in this
message you raise the possibility of a new construct: an LTA
(LISP Translation Aggregator).  Point 6 mentions a (sub)set of
LTAs advertising "their aggregated EID-to-RLOC mappings" to the
existing global routing table.  Maybe that means something like
what I propose for Ivip ITRs.

Dino protested on 15 June (Re: ViP: Anycast ITRs in the DFZ &
mobile tunnels):

> Robin, this is LISP 1.5, don't you realize that? In LISP 1.5,
> when EIDs come out of PI space, they cannot be routeable via
> the BGP Internet, so they use another topology that does carry
> EIDs. This is exactly what you are describing above.

You and probably Dino have a much more concrete idea of LISP 1.5
than I am able to create in my own mind by reading what little I
have to go on.

I am not convinced Dino understood correctly what I had in mind
when I wrote my first piece.  Hopefully, seven long Ivip
messages since then will enable anyone with sufficient patience
to have a clearer idea of what I am trying to communicate.  I
plan to write a much more accessible I-D in August.  For now,
links to the longer messages I wrote are at:

  http://www.firstpr.com.au/ip/ivip/

I got no idea from your LISP I-D:

  LISP 1.5:  where EIDs are routable for bootstrapping
             EID-to-RLOC mappings; such routing is via a
             separate topology.

that LISP 1.5 involved any router advertising prefixes
containing EID addresses to the rest of the BGP system.

It is five months since you released the LISP I-D and I suspect
I am not the only one who is struggling to create a concrete
example in their minds of LISP 1.5.  Anything you can write by
way of examples would really help.

 - Robin

---

From: Michael <[email-masked]>
Date: Fri, 29 Jun 2007 15:51:49 +0800

----- Original Message ----- 
From: "Robin Whittle" <[email-masked]>
To: <[email-masked]>
Sent: Monday, June 25, 2007 2:56 PM
Subject: Re: [RAM] Preliminary thoughts on LISP 1.5

> what I propose for Ivip ITRs.

according to the LISP, their aggregattion degree of EID-to-RLOC mappings depends on where the ITRs are allocated.