[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 21:40 Europe/Amsterdam, Pekka Savola wrote:
It allows around ten million multihomed networks, so that answers the
useful part. Nobody has ever pointed out any aspect that presumably
wouldn't work (just stuff they aren't real comfortable with) so either
I am as smart as I think or nobody wants to take the time to carefully
read the draft.
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
What's so hard to understand??? In the US you create an aggregate route
for the US address block and you accept /48s for US destinations. In
Europe, you create an aggregate for the European address block and
accept /48s for European destinations. So when you have a packet in the
US that needs to go to a European destination, you don't have a /48
route so the packet is routed to Europe by means of the aggregate. In
Europe, the packet is routed further as per the /48 that is in the
routing tables of European routers. Rinse, repeat.
"ouch! I don't really understand the idea, but it still gives me
If you want to avoid that feeling, you must warm up the folks properly
So how do I do that? Buy everyone drinks at the IETF meetings?
"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
of AS is broken"
Ok, then OSPF and IS-IS explicitly support broken networks...
In your proposal, what is the thing you're worried of? International
transits which are part of all the different continents and regions?
I'm not worried.
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
Not sure what you're getting at.
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.
But just now you said you wanted to be able to have the same routing
info in all routers! You can't have it both ways.
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
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?
If you have a better idea, I'd like to hear it. The trouble with a
situation where routers only hold a partial table is that the traffic
has to physically move to the place where the routing information is.
This is incredibly inefficient, _unless_ the place where the routing
information is happens to be in the right direction of where the
traffic has to go to anyway.
.. Whether "geographic" split makes sense is a different thing though.
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.. :-/
Tell me what's missing and I'll put it in.
Actually Tony's draft is just an addressing scheme which doesn't
automatically solve routing.
I don't mean solving all routing problems forever, just that Tony's
scheme needs additional routing stuff to do something useful.
I'd be very very careful of any mechanism which claimed would solve
If someone in Asia wants to connect through European ISPs, that's
Well, once the routes hit the dfz, it becomes your problem too.
Not if I filter them out. :-)
I did some messing around with BGP yesterday. 4000 routes are
responsible for 60% of all our traffic, 6000 routes for another 25%.
that means I can have optimal routing for 85% of all traffic with just
10% of all routes. That's good enough for me.
Your milage may vary. If you mainly host websites in the local language
this is going to be very different from a situation where you connect
the rooms of a big convention hotel.
Nice to get some figures, however, I can already hear the 10% yelling
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%
them were /24's. Those only covered 1.7% of all the advertised address
Interesting figure, eh? I guess it's no wonder that less than 5% of
What really annoys me to no end is the people who announce 10, 20, 100,
200 /20s that could easily be aggregated. Some of the people announcing
/24s are doing this for good reasons, but people filter on the /20
boundary and hurt exactly the wrong people.
eat up at least 75% of the routing table entries. I guess that shows
something about routing tables.
I don't understand why the large networks don't do anything about this.
I would simply de-peer.
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.
What exactly would another ISP have to do so I can aggregate within my
own network??? If I want to accept all routes within 220.127.116.11/8 in
Amsterdam, all routes within 18.104.22.168/8 in London and so on, I can do
that without cooperation. (I have to deaggregate if I don't peer in
London with someone who announces 22.214.171.124/24, though, but that's
still something I can do on my own.)
Forgive me for sounding skeptic, but I'm not as sure without further
analysis that no cooperation would be required.