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

Mon Oct 8 20:38:30 UTC 2001

On Sun, 7 Oct 2001, E.B. Dreger wrote:

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

There are many ways this could work.

I think a system where addresses are used in a smaller area would probably
be better: you can always decide to accept Kansas addresses in Chicago or
New York or Madrid if you want (as long as ISPs announce customer routes
everywhere), but once some people in Kansas only connect to Dallas and
others only to Chicago, some of the advantage is lost: you have to connect
to both.

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

Suppose we are both global networks, but we interconnect only in a few
places. Suppose my idea of Kansas is "north" and yours is "south".
Obviously, if we could agree on an interconnect point where routes to
Kansas belong, we both wouldn't have to carry more specifics than the
regional aggregate outside this region. But if I accept your Kansas routes
in Dallas and you mine in Chicago, everything still works, there are just
no savings.

> Let's take this a step further.  Say that we divide the US into
> these "major hubs":

[...]

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

Yes, but what if there is no overlap? If two networks only know those
routes in that part of the country, but don't interconnect in that region,
there is a problem and more specifics have to be carried throughout a
larger part of the networks. However, a network that doesn't interconnect
in this region can accept Denver routes in the Bay area and Chicago routes
at the Sprint NAP, if Denver and Chicago use different regional prefixes.

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

I don't think many people will renumber for this. And it only applies to
multihomers anyway, routes from well-aggregated PA space will presumably
still be carried world wide.

As long as we're on the subject: it wouldn't hurt if the regional
registries looked at allocating bigger chunks of address space to large
ISPs. There are ASes that announce hundreds of routes. That's not good. It
seems like the RIRs are afraid to carve off big chunks of address space.
Why? Assigning someone a /16 and keeping the next 15 /16s free in case he
comes back soon doesn't mean those 15 /16s can never be allocated to
anyone else any more. But giving someone a /16 and the next person the
next /16 DOES mean the first one will never be able to aggregate two /16s
into a /15.

Iljitsch van Beijnum