[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: provider-int geo aggr [Re: plug: thesis on site multihoming]
On zondag, maa 30, 2003, at 19:37 Europe/Amsterdam, Pekka Savola wrote:
If the max number of routes a router implementation can handle is N and
more-or-less-complete routing table (non-existant but as a concept)
be Y (>N), you require that each ISP would have at least Y/N (rounded
routers each connected separately
Each separately connected to peers. If they are "connected to the
internet" that would be a default route which you can have in just one
location if you want.
to the Internet
Yes. So it doesn't scale forever but one order of magnitude is no
problem at all and a second one (20 or so interconnects per continent)
should be doable.
-- that, between
operators you'd have at least Y/N (rounded up) interconnections if you
wish to have optimal paths, etc.
Forgive me saying this, but this kind of model which requires a lack of
aggregates in the core, and sets requirements for ISPs' border routers
just doesn't seem to fly.
My argument as an operator is that unless you can divide & conquer the
I'm not entirely sure what you're saying. Is it "if you can't hold the
entire DFZ in a single router your architecture is broken"? That's one
view. I'd say it's the other way around: if your architecture requires
you to keep information about the entire world in all routers, you've
painted yourself into a corner.
full routing table to such proportions that it can't be uniform in one
there's something very broken in the design of the internet routing
Forget current practices for a moment. Doesn't it make sense to keep
detailed information about local stuff and not so detailed information
about what happens farther away?
Certainly, the basic concepts of how these different routers with
I'm considering an update to the draft, but as far as I can tell
everything is in there.
knowledge interact with peers' and upstreams' routers of partial
seems quite fuzzy .. and this is one thing that seems critical to have
clarified (some pictures might be illustrative).
Actually Tony's draft is just an addressing scheme which doesn't
automatically solve routing. My geo proposal could use Tony's
addressing scheme. (But Michel and me have written a draft of our own
for this, you can find it under "GAPI".)
But as this seems a different proposal than Tony's, I'll remove the
It all boils down to the question: why would someone in Europe need
more specifics for people in the US, or vice versa?
Fortunately, the days of transatlantic routing between two places in
Europe are long gone. In other parts of the world this still happens,
but I believe this will sort itself out for the most part before
multihoming in those places becomes so popular the multihomed prefixes
must be aggregated.
Depends on the level of interconnection and how the routes are set up,
Currently, there is no abstraction, so it's difficult to estimate..
If someone in Asia wants to connect through European ISPs, that's their
if there was, people would probably very much like *their* pretty
route going through optimal paths and being in the full routing table
all the routers.
I did some messing around with BGP yesterday. 4000 routes are
responsible for 60% of all our traffic, 6000 routes for another 25%. So
that means I can have optimal routing for 85% of all traffic with just
10% of all routes. That's good enough for me.
I haven't really been able to form a picture in my head how the
Cooperation from other ISPs is not needed: everyone can implement or
not implement this as desired, just as long as the RIRs give out the
addresses based on geography.
would have to be practically enabled for example through a path from an
European ISP to U.S. ISP, in between having or maybe not having
and ISP's which may or may not honor this model.