On Sat, 27 Jul 2002, Ralph Doncaster wrote:
Worse for those two transit providers, not the rest of the world.
Why won't the rest of the world see extra hops and increased latency reaching my network (for the 50% of the time that the wrong transit provider is picked).
Because you could *gasp* be intelligent with your network design and do things like purchase transit from the same carriers in both your serving markets. Announce the /20 everywhere, announces your /23/whatever out the local connections for that city with no-export attached. The two carriers you *pay* for transit hold the more specifics to route the last leg to you, the rest of the world doesn't need or have to receive your deaggregation. This also gives added benefits like not slamming your inter-city circuits quite as hard when your link to one of your upstreams goes down. The problem here Ralph is that you see absolutely no problem with doing things on your network that have minimal benefit to you, yet have global impact. There's currently around 23-24k prefixes out there that are more specific announcements from the same origin AS as the aggregate. If all that junk would somehow magically get cleaned up the extra prefixes seen from multihomed networks announcing holepuncheed provider owned space would be _much less significant_, and RIR filters probably wouldn't even be necessary. You claim that your announcements have no global impact.. just like the thousands of others just like them, right?
The proposed "fix" is a big mess. My solution doesn't add to the global routing table since I'm renumbering out of a few /24's to the /20 I received from ARIN. I'm only de-aggregating to a /23, not /24. My solution provides optimal routing vs announcing the /20 globally.
Your network is the mess, not the solution. You've been given a /20 from ARIN, the responsible thing to do would be to do everything you can to make sure 90% of the internet sees that /20 and only that /20. The other 10% would be the people you pay money to for transit service who happily accept more specific prefixes because you are their customer.
The proposed "fix" will waste bandwidth, increase latency, and far more problematic to implement; how many NOC monkeys do you know that will be able to grasp the purpose of the 2 BGP sessions (one of them ebgp-multihop) let alone fix it if something goes wrong?
http://www.ietf.org/rfc/rfc2519.txt http://www.ietf.org/rfc/rfc1771.txt Typically one does not call another a "NOC monkey" unless they have demostrated to have a higher level understanding of the technologies at play. - Paul