Request for Comments on a topological address block for N. Calif.
This has been brought up before and discussed to no final conclusion. I am more interested at this point in actually doing something, so I would like to issue a final-round-of-discussion request for comments prior to making this happen. I propose that a large block (say, /8 to /10) be allocated to an independent authority which will then reallocate growable blocks to small to mid level ISPs in the northern california region who are connecting via providers attached to MAE-W, CIX, or PacBell's NAP and topologically "at" those connect points. These addresses can then be filtered out of announcements to routers anywhere else in the world and replaced with a /8 aggregate announcement; only routers within the topology zone would require full information on the connected entities. These addresses will be relatively easy to dual-home within the area, yet will have minimal impact on the global routing infrastructure. To minimize the number of routes announced within the area, all addresses assigned would be sufficient for 6-month in the future at demonstrated growth rates, and reservations for up to 18 months in the future at demonstrated growth rates would be made when possible (giving the inherent ability to grow /20's to /19s and /18s etc. rather than have to make a new announcement). A minimum size of /20 would be required for entrance; smaller ISPs would have to go through traditional allocation-from-their-upstream-provider channels. This would tend to make brand new startups avoid cluttering the space until their growth was established and measured. Some sort of nominal fee on the order of $1 to $2.50 per /24 equiv would probably support the operation just fine, which should be within the range nobody will object to. Comments, suggestions, pointing out of fatal flaws or anyone stating they will be completely unwilling to go along with this are solicited (though I would appreciate an explanation for objections or refusals 8-). Thank you. -george william herbert gherbert@crl.com
I propose that a large block (say, /8 to /10) be allocated to an independent authority which will then reallocate growable blocks to small to mid level ISPs in the northern california region who are connecting via providers attached to MAE-W, CIX, or PacBell's NAP and topologically "at" those connect points. These addresses can then be filtered out of announcements to routers anywhere else in the world and replaced with a /8 aggregate announcement; only routers within the topology zone would require full information on the connected entities. These addresses will be relatively easy to dual-home within the area, yet will have minimal impact on the global routing infrastructure.
I don't think that this will work for a business viewpoint - someone will end up giving at least some of these ISPs free transit. See the attached message that I sent to big-internet earlier this month. My comments apply to metro-based addressing or interconnect-based addressing or similar schemes. --asp@uunet.uu.net (Andrew Partan)
From: asp@uunet.uu.net (Andrew Partan) Subject: Geographinc addressing To: big-internet@munnari.OZ.AU Date: Mon, 4 Sep 1995 22:33:41 -0400 (EDT)
People have talked about geographic addressing.
Lets look at this in a bit more detail.
Lets assume that everyone on the Boston area has a geographic address and that AlterNet and some other ISP (SmallGuy) have some customers in this area, and that AlterNet and SmallGuy peer at some Boston area exchange point.
Now AlterNet has to have explicate routes to all sites in the Boston area - our own Boston customers plus all Boston customers of all other Boston ISPs. Humm, I don't see any aggregation here. But to continue.
Now the idea is that outside of the Boston area, all ISPs will aggregate all Boston area routes (for all of their own customers and all customers of all other Boston ISPs) into one large Boston route.
Now if I peer with some other ISP in some other area (say someone in San Francisco), then I am supposed to send them just one route for the Boston area.
I have now suddenly offered transit for SmallGuy between San Francisco and Boston.
If SmallGuy is not paying me for transit, then I am not going to do this.
The only way of not doing this is to not advertise the single Boston route, but rather to advertise all of my Boston area customers individually - suddenly no more aggregation.
So either there is free transit or no aggregation.
Geographic addressing is not going to fly. --asp@uunet.uu.net (Andrew Partan)
I see your point (and remember your earlier message), but that's not a show stopper. To be in that situation, the small ISP has to have bought ISP access connectivity from one or more ISPs in those geographically disparate locations and not have them find out what's going on. If, say, mountainview.net (which is fictional (I hope 8-)) branched out to Miami, and bought another Alternet ISP T-1 connection out there, they would then be getting free transit between them. Presumably if both were Alternet connections, you'd figure it out. If they bought Sprint access in Miami, then they might fool both of you. You could easily avoid this by adding a statement to your service contracts for addresses allocated from these geographical block(s), which states that there must be full disclosure to all involved upstream providers if the company adds sites outside that area. If they fail to do so they would then be defrauding you. This is a matter for you to work out with your customers, so it's not really the address blocks' managements' issue. You just have to keep a slight eye on people using the block space. The basic problem isn't with geographical addressing per se. It is possible for unscrupulous end users to set up things like this, with transit achived surrepticiously (or an ISP claiming not to be to get the cheaper connect) already, and I'm sure in some cases it is happening. Proper policy and awareness is required to deal with it at whatever level it appears, geographical addressing being one such level. -george
George, Let's take a clear example: Let's use 39/8 as the Bay area prefix. Suppose that mountainview.net gets 39.1.1/24 (just to be simple). Suppose that they happen to connect to Fix-west but not to the SF NAP. Suppose that sunnyvale.net gets 39.100.100/24 and connects to the NAP and not to Fix-west. Now, we can't summarize 39/8 into the backbones at either of the two locations. Consider what happens if a backbone with only 39/8 delivers a packet to the NAP for mountainview.net. What happens? In fact, we have to move the AAB out. And we have to at least subsume a biconnected (or triconnected?) subgraph of the backbones that contains the interconnects. The result is that we either summarize 39/8 to the backbones and someone provides free transit between the NAP and Fix-West, or we get no effective aggregation from 39/8. Tony
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
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. Well, in that case, the user should CLEARLY get a prefix from the service provider. 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. This is exactly the free transit that we've been describing. And you'll note that you have no aggregation as Sprint now has a longer prefix running free internally. 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 was Ran's proposal. While this works, you have to understand what it doesn't do: it doesn't eliminate the need for renumbering. What happens when you flip from one interconnect to another? 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. Well, I agree that more coordination is a good thing. This is the place to do it. But arguing about address allocation strategies again isn't useful. We should be at the point of fine tuning them. 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. Wow. What do you think the previous flame-fest was about? Tony
Btw, has NRL returned 39 or was that just random? 8-) Intentionally the number of our CIDR experiments. Tony
Btw, has NRL returned 39 or was that just random? 8-)
-george
Network Working Group IANA Request for Comments: 1797 ISI Category: Experimental April 1995 Class A Subnet Experiment Status of this Memo This document defines an Experimental Protocol for the Internet community. This does not specify an Internet standard of any kind. Discussion and suggestions for improvement are requested. Distribution of this memo is unlimited. ... To further this experiment the IANA will temporarily designate the class A network number 39 to be used in the following way: The high order octet of the 4-octet IPv4 address is the class A network number 39. There are two cases for low order 24 bits. ... --bill
I should have put all this off until my brain was done recovering from LISA. -george
I don't think that this will work for a business viewpoint - someone will end up giving at least some of these ISPs free transit.
See the attached message that I sent to big-internet earlier this month. My comments apply to metro-based addressing or interconnect-based addressing or similar schemes. --asp@uunet.uu.net (Andrew Partan)
The one way around this is to have all of the players participating in such a scheme form a "co-op", so that "long-haul" folks only sign one transit agreement, with the co-op. A few tweeks to the MPLA's at the AADS and PACBELL NAPS, regarding this technique might fly. At least they are a starting point for such discussions. -- --bill
participants (4)
-
asp＠uunet.uu.net -
bmanning＠ISI.EDU -
George Herbert -
Tony Li