Date: Sun, 7 Oct 2001 22:38:44 +0200 (CEST) From: Iljitsch van Beijnum <iljitsch@muada.com>
[ snip ]
10 to 20 regions means about three regions to a continent. That's not too unreasonable.
Furthermore, nothing says that there must be a mapping stating "this IP space is for this one region". Let's say that, in the U.S., CHI is the base for "north", DFW for "south", D.C. for "east", and Bay area for "west". All except E/W are valid combos. (e.g.: being in KS, I could be in "north" or "south", connected to CHI or DFW.) The number of region combos is "4 choose 2 minus 1", or 5: + N/E 126.0.0.0/11 + N/W 126.32.0.0/11 + N/S 126.64.0.0/11 + E/S 126.96.0.0/11 + W/S 126.128.0.0/11 Assign IP space based on one of those regions...
Sift things around for a few years and you have people in that region connecting to every possible backbone provider plus most of the 2nd tiers and misc other countries.
...rinse and repeat for E-US/W-EU, W-US/E-JP, etc.
But Asian/Australian networks tend to connect to the US west coast, European networks to the US east coast. And even if a relatively large number of exceptions exist, savings are possible.
I agree. Any comments on my above overlapping system? It's virtually impossible for one to no longer connect to one's "home" region. If "two closest points" isn't flexible enough, we can move to three closest points: "N choose 3 minus invalid_combos" is still fewer routes by far than the status quo. Let's take this a step further. Say that we divide the US into these "major hubs": Seattle, SF Bay, LA, San Diego, Phoenix, Salt Lake, Denver, DFW, Kansas City, Saint Louis, Chicago, Atlanta, Miami, D.C., NYC, Boston, Philadelphia, Twin Cities. Yes, I'm ignoring many cities. So what. This is an example... everyone feel free to tear it apart and improve upon it. I count 18 different hubs. Now let's say that we divide address space such that it a given netblock can be native to any of five different hubs -- "18 choose 5" different netblocks = 8568 netblocks. Now consider how many are invalid... the actual number is much lower. Using this logic, we can divide the entire CONUS into a few thousand netblocks. Let's say that I use 125.100.75.50/24. Let's further assume that this is in 125.96.0.0/11, which is "KC+STL+CHI+DFW+DEN". Any backbone provider servicing me in Wichita probably will connect to one of those hubs. I announce my /24 to Savvis and GBLX. They announce to peers. Peers can agg geographic traffic as they please. Someone in NYC who uses Sprint only sees 125.96.0.0/11, and knows that Sprint can get there... and that's all that matters. To get from NYC to Wichita, Sprint will interconnect with Savvis or GBLX in KC, STL, CHI, DFW, or DEN. I know that this creates peering problems, and the system won't quite work as stated... but I'm trying to brainstorm to the list in hopes that _something_ will come of it.
Didn't we have this argument with 8+8 ?
I wasn't there... But the argument shouldn't be about how much this will help, but about how much it will hurt. I don't think it will hurt anyone, so even if there is just a chance that it will help, we should do it.
Sort of... renumbering for naught is a bad thing. However, using a new, even marginally better, policy on new IP space would help. Back to server building... Eddy --------------------------------------------------------------------------- Brotsman & Dreger, Inc. - EverQuick Internet Division Phone: +1 (316) 794-8922 Wichita/(Inter)national Phone: +1 (785) 865-5885 Lawrence --------------------------------------------------------------------------- Date: Mon, 21 May 2001 11:23:58 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <blacklist@brics.com>, or you are likely to be blocked.