[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:


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

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

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 definition
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 aggregate?
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.



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.




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.




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.




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.




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'd be very very careful of any mechanism which claimed would solve
routing automatically.




I don't mean solving all routing problems forever, just that Tony's 
scheme needs additional routing stuff to do something useful.




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.



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




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.




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.



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.



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.





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




What exactly would another ISP have to do so I can aggregate within my 
own network??? If I want to accept all routes within 195.0.0.0/8 in 
Amsterdam, all routes within 196.0.0.0/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 196.12.34.0/24, though, but that's 
still something I can do on my own.)