Re: provider-int geo aggr [Re: plug: thesis on site multihoming]

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

On dinsdag, apr 1, 2003, at 12:27 Europe/Amsterdam, Kurt Erik Lindqvist 
wrote:

> I would still like to second Pekkas request on an example with AS:es 
> instead of routers.
The AS view is exactly the same as today: each AS announces its 
customers (and customer's customers) to peers and upstreams.

> What I am not sure I understand is who would have to provide the 
> transit between the AS:es for these /48s?
It seems the word "geography" carries a lot of baggage in this context. 
Forget all of that. The only thing I want to do is remove routing 
information from the places where it doesn't actually help routing.

To answer your question: the transit relationships would be identical 
to what happens with PI today. So if A is a customer of B which is a 
peer of C which has a customer D, the traffic would still flow A -> B 
-> C -> D and D -> C -> B -> A. However, if A is in Seattle and D is in 
The Hague, today the A -> D traffic would be flow from B to C close to 
the origin, so probably somewhere in the bay area. The D -> A traffic 
would also flow from C to B close to the origin, probably in Amsterdam.

With provider-internal geo aggregation B would no longer have the route 
for D in routing tables on the US west coast. (C would still announce 
this route there, as C doesn't know how B aggregates internally.) So 
the traffic for D will be routed according to an aggregate. This could 
be a route for all of Europe, or the Netherlands or The Hague. Then at 
some point the packet arrives on the US east coast, in Europe, NL or 
The Hague, and there the /48 is in the routing table and the packet is 
transferred to C.

>  Also, what do you do with Tier-1 providers and customers that are 
> multihomed to different continents?
There are three cases:

1. Geographically diverse organization that doesn't want to use its 
private network for "internal transit" (having ISPs transport the 
traffic to the right location is cheaper): simply use GAPI addresses in 
each location. This means that each location must multihome 
independently.

2. Geographically diverse organization that wants to use its private 
network for "internal transit": they are assuming an ISP role here so 
they should get their own PA block. Note that this means the entire PA 
block is announced in each location so lots of internet traffic 
traverses the private network.

3. Organizations that use long distance links to connect to the net. A 
good example would be satellite links. There is no good solution for 
this situation: either the organization breaks aggregation or it uses 
addresses from the "landing site" geo address block rather than the 
user site geo address block.

Note that not solving 100% of all cases isn't a problem: we don't need 
a 4k routing table, we just need to avoid a 4M routing table. A 400k 
routing table in the year 2008 or so would be just fine. So we can 
still allow a reasonable number of all multihomers to break aggregation.

> Could you write a bit more detailed example?
Is the above what you need?