North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

RE: The Gorgon's Knot. Was: Re: Verio Peering Question

  • From: E.B. Dreger
  • Date: Sun Oct 07 18:25:33 2001

> Date: Sun, 7 Oct 2001 22:38:44 +0200 (CEST)
> From: Iljitsch van Beijnum <[email protected]>

[ 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 <[email protected]>
To: [email protected]
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 <[email protected]>, or you are likely to be blocked.