I was assuming that for the most part, the end users of these addresses
are going to be connecting via a larger transit provider, not directly
to the interconnects. In any case, all routers in the area we draw the
abstraction around will have to know where everyone else is...
Presumably, if mountainview.net is connected to sprint via a router
at fix-w, then the sprint presence at mae-w and the NAP will announce
that next-hop for mountainview.net is via them. Incoming packets that
hit the NAP will then go via sprint for the last hop.
For people who are directly connecting to an interconnect, then there
would have to be some sort of additional agreement with someone who
had presence at the other interconnects within the defined boundary
for transit from one to the other in this case. Lacking such an
agreement, things would get lost if they came into the area at the
wrong interconnect. This is additional hassle, but I suspect that
that sort of agreement is less hassle than the effort involved in putting
your own router in an interconnect (or running a fast line to one).
It raises the effective entry level for going directly to an interconnect
a bit, in exchange for easier ip space allocation and helping to save
the rest of the worlds routers. Perhaps large backbones would offer
the transit for free as a benefit for using this abstraction, since
the large backbones are the ones facing the router problems.
I don't know; this needs more discussion.
Another alternative, if the big backbones around here object to
that complexity, is to put a smaller version of this at each of the
local interconnects (a /9 at the NAP, a /9 at MAE-W, ...) rather than
draw the boundary around all the interconnects inclusively.
This would require that the end users choose where they would
be connecting, which limits their future flexibility some but
not necessarily too badly. Or we could just pick one interconnect
and make it the official one with the addresses, leaving the others
for backbones and highly connected mid and large sized ISPs to peer.
I am not trying to make this thing work before the idea is really
cooked well enough, but to really make a serious dent in announcements
then we need to look at constructs like this, if not identical to this,
becoming more standard. Right now, larger ISPs aren't getting large
blocks, and they are allocating things in non-contiguous non-growable
blocks, neither of which is good. Nothing is being done to organize
topological assignments at all, which is seriously not good.
I see this as a potential strong first step towards demonstrating
what we can do by topologically assigning things. I haven't seen
serious proposals for better topologically significant assignments.
We have to start somewhere.