[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: provider-int geo aggr [Re: plug: thesis on site multihoming]
On dinsdag, apr 1, 2003, at 12:27 Europe/Amsterdam, Kurt Erik Lindqvist
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
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?