Subject: [RRG] LISP etc architecture

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 17 Dec 2007 13:12:55 +0100

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 [email-masked] 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

---

From: Christian Vogt <[email-masked]>
Date: Mon, 17 Dec 2007 20:23:14 +0200

Iljitsch -

> this is the case right now.

I don't think either that this is the case since the mode of deployment
is, IIUC, exactly what distinguishes APT from LISP:  APT aims for
deployment in ISP networks -- first locally within ISP borders, later
across ISP borders --, and LISP aims for deployment in edge networks.

Alternative deployment is not always possible:  While I don't see a
reason why APT could not be deployed also in edge networks, LISP is IMO
tailored to deployment in edge networks because it uses the edge
network's interior gateway protocol to synchronize status information
between ingress tunnel routers.

- Christian

---

From: "Juan Jose Adan" <[email-masked]>
Date: Thu, 20 Dec 2007 12:04:37 +0100

Hi Iljitsch,

I agree with many of the points you have raised in
your note. In my draft on "Tunneled Inter-domain
Routing" (TIDR) that I sent to the IETF a year ago
I covered some of these points. Please see below.

> reason for (locator) addresses on the ground floor to be globally

In TIDR I proposed to use a specific set of addresses
for locators (240.0.0.0) that would be assigned to
transit AS-es. Transit AS-es would then originate
"locator prefixes" that would be use for the dynamic
inter-AS connectivity of the "ground floor". One of
the main benefits of this is the protection of the
inter-domain routing infrastructe because a packet
coming from a non-transit AS with destination within
the 240.0.0.0 block will be stopped as it enters
the inter-domain routing infrastructure. In other
words the first non-transit AS will discard that
packet. And a transit AS will never accept IP
packets with an IP destination in this range UNLESS
it is a tunneled packet.

> considered a design flaw in BGP. For some time now, the number of

In TIDR we have the possibility of announcing one
or more "locator prefixes" per AS.

> floor:

Pruning of leaf AS-es is the base of the reasoning
that I followed in the TIDR draft. Leaf AS-es don´t
participate in the inter-domain packet forwarding,
while at the same time contribute to the size of
the global BGP table. They also consume AS numbers.
They don't play in the football team but they have
a number reserved for their shirt. :-)
And finally, they are 5/6 of the total number
of AS-es, roughly speaking.

rather than map a prefix to a single leaf AS, we need to map a
> fragments when it runs out, in my opinion, this isn't all that likely.)

In TIDR, "identifier prefixes" of a leaf AS can
be mapped by all the upstream ISPs. Only transit
AS-es are allowed to map "identifier prefixes" to
"locator prefixes".

> MPLS,

I think this point is important. In TIDR one can
specify several tunneling techniques, IP-in-IP,
GRE, or even an MPLS label. Two peering AS-es
could announce between them the mapping of
"identifier prefixes" to specific MPLS labels.

Regards,
Juanjo