[RRG] LISP etc architecture

[Iljitsch van Beijnum <iljitsch@muada.com>]

It seems to me that the basic architecture behind proposals like LISP  
is that we separate two things:

1 the dynamic inter-AS connectivity (I'll call this the ground floor)
2 the mapping from prefixes to ASes (I'll call this the second floor)

Where 2 itself can be split into:

2a the fairly static mapping of prefixes to a set of ASes
2b the dynamic reachability status of each individual prefix->AS  
relationship

LISP is of course somewhat messy because it wants to be highly  
backward compatible. In a more radical approach, there isn't even any  
reason for (locator) addresses on the ground floor to be globally  
unique: see HRA.

Doing routing calculations per prefix rather than per AS could be  
considered a design flaw in BGP. For some time now, the number of  
prefixes per AS has been stable at close to 8.5. Interestingly, new  
ASes tend to have far fewer than 8 prefixes, so what's really  
happening is that the influx of new ASes and the addition of new  
prefixes coincidentally happen at the same rate. In the two floor  
system, we immediately gain an order of magnitude in processing  
reduction, but this is a one time thing that may not even translate to  
IPv6, where the AS-to-prefix ratio is about 1.4. the real savings will  
have to come from the ability to prune leaf ASes from the ground  
floor: rather than map a prefix to a single leaf AS, we need to map a  
prefix to multiple transit ASes, or we're stuck with the one-time gain  
if we assume the number of prefixes per AS isn't going to go up. (Some  
people argue that this is exactly what will happen as the IPv4 space  
fragments when it runs out, in my opinion, this isn't all that likely.)

One thing that remains unclear in both the LISP draft and discussions  
about LISP is where ITRs and ETRs are placed. For ITRs, these are the  
options:

1 source site
2 source ISP (close to the source site)
3 destination ISP (close to the source ISP)

For ETRs:

A source ISP (close to the destination ISP)
B destination ISP (close to the destination site)
C destination site

Which gives us the following permutations:

Obvious choices are 1C and 2B. The problem with 1C is that there are  
very many sites and the alignment between cost and benefit is less  
than optimal. So starting with 2B and then slowly moving to 1B/2C/1C  
seems like a better deployment model. However, even 2B may be hard to  
get off the ground. Ideally, 1A and 3C should provide benefits to  
individual ASes.

This means that it's important that mapping systems are designed such  
that they can be deployed in each of the A/B/C scenarios. I'm not sure  
this is the case right now.

Another thing that slightly worries me is that LISP is only focussed  
on IP-in-IP tunneling, ignoring all the work that has been done on  
MPLS, which would be an obvious choice for any 1A/3C deployments. And  
that's just what's available today, with the proliferation of optical  
switching, much more interesting tunnel approaches may present  
themselves. It would be much better if we could create a modular  
architecture where there are different choices for each of the  
mapping, reachability and encapsulation/decapsulation components.

--
to unsubscribe send a message to rrg-request@psg.com with the
word 'unsubscribe' in a single line as the message text body.
archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg