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

[Pekka Savola <pekkas@netcore.fi>]

On Sun, 30 Mar 2003, Iljitsch van Beijnum wrote:
> > 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?

Can you require all of these things from all the folks?

But really, the problem is that I'm having hard time (and based on the
lack of enthuasiasm from the others, the rest as well)  figuring out
whether the model could be useful and whether it could actually work.

It just doesn't seem to be enough fleshed out to say much other than
"ouch! I don't really understand the idea, but it still gives me creeps!".  
If you want to avoid that feeling, you must warm up the folks properly :-)

> > 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. 

If you note, I explicitly did not say that.  I said (or tried to, I was 
not precise), that:

"if you can't have the same routing table in all of your routers in a
single AS while being part of the DFZ, your architecture or the definition
of AS is broken"

In your proposal, what is the thing you're worried of?  International 
transits which are part of all the different continents and regions?

In the proposal, where are the more specific advertisements hidden?  
Being advertised between different AS's at peering points but hidden in
your that particular peering router by an internally advertised aggregate?

> 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.

I can agree with that (which is the addressing model Tony is proposing 
with his geo proposal, btw.) -- if it's required, but I'd like to avoid 
it.
 
> 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?

Yep.  

.. Whether "geographic" split makes sense is a different thing though.
 
> > 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.

Doesn't seem to be particularly unenlightened-friendly.. :-/
 
> > 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. 

I'd be very very careful of any mechanism which claimed would solve 
routing automatically.

> 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".)

Yep, been through it.
 
> >> 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.

.. with current topology-derived addressing...

> > 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.

Well, once the routes hit the dfz, it becomes your problem too.
 
> 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.

Nice to get some figures, however, I can already hear the 10% yelling
quite loudly..

I also made a rough sketch on more specifics (it's in 5.3.1).  In an
exchange in Finland, 1661 prefixes were advertised some time ago.  50% of
them were /24's.  Those only covered 1.7% of all the advertised address
space though.

Interesting figure, eh?  I guess it's no wonder that less than 5% of folks
eat up at least 75% of the routing table entries.  I guess that shows
something about routing tables.
 
> > 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.

Forgive me for sounding skeptic, but I'm not as sure without further 
analysis that no cooperation would be required.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings