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