[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) would
be Y (>N), you require that each ISP would have at least Y/N (rounded up)
routers each connected separately
Yes.


to the Internet
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.

-- that, between
operators you'd have at least Y/N (rounded up) interconnections if you
wish to have optimal paths, etc.
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.

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.

Why not?
My argument as an operator is that unless you can divide & conquer the the
full routing table to such proportions that it can't be uniform in one AS,
there's something very broken in the design of the internet routing
architecture
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.

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 partial
knowledge interact with peers' and upstreams' routers of partial knowledge
seems quite fuzzy .. and this is one thing that seems critical to have
clarified (some pictures might be illustrative).
I'm considering an update to the draft, but as far as I can tell everything is in there.

But as this seems a different proposal than Tony's, I'll remove the
reference.
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".)

It all boils down to the question: why would someone in Europe need
more specifics for people in the US, or vice versa?



Depends on the level of interconnection and how the routes are set up,
there.




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.




Currently, there is no abstraction, so it's difficult to estimate..  
But

if there was, people would probably very much like *their* pretty 
little

route going through optimal paths and being in the full routing table 
of

all the routers.



If someone in Asia wants to connect through European ISPs, that's their 
problem.



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 
proposal

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 
transits

and ISP's which may or may not honor this model.



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.