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