Yakov,

...

It's the other way round: SPRINT should tell his customers he can't guarantee 100% global Internet connectivity because he disagrees with the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC.

Would you assume that anyone whose address allocation follow "the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC" is guaranteed 100% global Internet connectivity ?

It is pretty hard to guarantee 100% of anything, but my guess is that "IANA/InterNIC/RIPE NCC/AP-NIC" would be willing to follow any sort of guidelines for how they should allocate address space such that ISPs would endeavour to do their best to route the resulting address topology. Even if this means always allocating in /17 units. The problem is that no one has ever bothered to set meaningful engineering goals for maximizing the life of IPv4. As far as I know the only targets we have are the entirely qualitative, warm-and-fuzzy ones of "smaller" forwarding tables and "better" efficiency of address utilization. So everyone goes off and implements their own policies to make things "smaller" and "better", and we make proposals for making things even "smaller" and "better" still, without the faintest idea of how to quantify "smaller" and "better" in a consistent fashion. So what end result could we have other than what what we got, which is people doing conflicting things, but perfectly justifiable things based on their own notions of "smaller" or "better", and then pointing fingers of blame at each other when the end result is broken, or doesn't conform to their own personal notions of "smaller" and "better"? And I don't think the inability to guarantee 100% of anything justifies ignoring the problem, or not dealing with it as the operational engineering issue that it is. It is broken, and an inability to make 100% guarantees doesn't constrain one from making an attempt to engineer a fix, where "engineer" should mean you have some ability to quantitatively evaluate the outcome. We've got a basic conflict between "smaller" and "better", whose resolution will require (in the absense of really good renumbering technology) constraining our insistance on efficient address utilization by measuring the effect this has on routing tables. We need to get some quantitative goals assigned to this so we can measure what is "good" and "bad". I'd (again) suggest the following: (1) Let's try to make a realistic estimate of what the end state for the IPv4 address space should be. I.e. how many (or few) routes should we be aiming at being able to carry by the time the address space is entirely allocated. Let's come to some consensus about what this number should be (call it 200,000 routes for the sake of current argument), document it, and have everyone include it in RFI's for future routers so that the goal, whatever it is, is clearly defined for hardware vendors (who can then complain if the target is unreasonable, so one can adjust it down accordingly). (2) Let's then look at the amount of extant global routing information from each class-A-sized space, keeping each one to the average required to meet the end-state estimate (about 900 routes per class-A to hit the 200,000 mark). We then squeeze down on existing blocks to fit into this (by imposing filtering, or whatever, if necessary). We also suggest that when any new block a registry is allocating from hits the magic route limit they quit trying to fill in spaces and go on to another class-A sized block (getting more efficiency out of the current block is useless anyway if we're not going to be able to route it). We don't worry about the length of individual prefixes, just the total routes for the block, as this gives registries some flexibility in accomodating both small and large providers and sites. (3) Then we can spend IETF meetings looking at charts with numbers which have real targets to compare them to, and bashing those with measureably bad numbers, and applauding those with measureably good numbers, and figuring out what to do if the numbers we picked look unachievable, or if we need new technology to do better. And otherwise actually engineering the problem, rather than just talking about how to get it "better" and "smaller". And I mostly think that the IETF group into which this issue fits is not doing its job unless it can get us to a point where address allocation people and ISPs aren't issuing disclaimers about each other's behaviour, and instead have got some mutually agreed upon, and verifiable, goals and targets which everyone works towards. Dennis Ferguson

Date: Thu, 25 Jan 96 14:46:29 PST From: Yakov Rekhter <yakov@cisco.com> Message-ID: <199601252246.OAA23511@hubbub.cisco.com> I have deleted almost everyone form the cc list (as have others) except I went further and deleted the IAB, IANA, etc as well... Would you assume that anyone whose address allocation follow "the current address allocation policy of the IANA/InterNIC/RIPE NCC/AP-NIC" is guaranteed 100% global Internet connectivity ? Yakov, this is a patently silly question, as the answer is either obviously yes by definition, or obviously no by demonstration. That is, one can define "the Internet" as being that set of IP reachable nodes which has connectivity to all of the other nodes in the set (and probably includes one specific node, say a.root-servers.net, just to distinguish this one particular set from other similar ones). In that case, by definition, if you are part of the Internet you are guaranteed 100% Internet connectivity - anyone you can't reach isn't part of the Internet. On the other hand, if we avoid precise definitions of what is the Internet exactly, then I can clearly show you nodes that generally consider themselves to be part of the Internet, which no-one (but a very limited number of nodes) can reach, and I expect many others can too, which easily shows that no-one, anywhere, gets 100% Internet connecivity. And I think you can see that address allocation policies actually have nothing whatever to do with this. However, Miguel does have a point, if Sprint choose to filter routes so that an advertismennt of mine is not visible to Sprint customers, then it is Sprint customers who are missing connectivity to me. I would only care on the assumption that I really wanted to communicate with someone silly enough to connect to a provider who would deliberately reduce their connectivity. We should also note however that filtering at /18 does not necessarily need to reduce connectivity, Sean has said he has that filter often enough, but he hasn't said that he doesn't also have a few other (perhaps static) routes of the form (say) 203.0/14 aimed at (say) MCI, so that while MCI (for example) may want to be sending 203.0.x/24 routes towards Sprint, Sprint can ignore them, and still retain connectivity to everyone. Connectivity remains that way, with some planning, though routing optimailty perhaps suffers, if MCI then had to hand off packets for some 203.0.z to some other provider that Sprint would (with full routing) have been able to reach directly. With a little application, the large ISPs could actually agree amongst themselves to divide up the routing table space this way - each agreeing to accept routes of "longer than optimal" prefix lengths for some subset of the entire table space, accept routes from all the others for lengthy prefixes and advertise only a short prefix route to all of them. While not a long term solution to anything, this would allow the current routing tables to to significantly reduced in all of the default free routers, which would also reduce the need to install draconian route filters throughout the net. Some routes would be longer, however it seems (to me at least, and certainly from imperfect knowledge) that this could largely be restricted to an extra high speed hop at (or near) the NAPs or other exchange points. That is, if implemented rationally this wouldn't require the providers maintaining longer prefix routes that are otherwise filtered in other providers to actually provide any long haul transit, just in and out of a single router. And last, as long as the routing tables continue to fit, anyone who wanted could continue accepting all the routes from everyone - the effect would be that when a provider was forced to filter to keep the routing system running that connectivity need not be sacrificed. kre

We are now closer to running out of Router capability than IP numbers to hand out. A rational solution to that would be to allocate IP space in a manner such that we don't run out of Router capability before we run out of IP space, by assigning easier-to-route, larger CIDR blocks to large providers, and allowing growth space in allocations so that small allocations can grow without having to add more announcements. If the allocating agencies continue to insist on being as sparing as possible with block allocations, which is noticably increasing routing problems, then we are going to face Internet partitions sooner rather than later, based on router load rather than running out of IP space. This is, in my opinion, a poor choice for overall growth.

But note well that current routers can't last forever (if you want them to we might as well give the next 120 requestors a class A chunk and then forget about address allocation altogether), and if you're looking for short-term relief address allocation policy is not the place to get it. Because the current forwarding table size is a result of the integral of all past allocation policies, it takes a while (a year or two, certainly, a lifetime in this industry) for any current address allocation changes to have any measureable effect. If you really need it, a much more effective method to get short term relief is to squeeze some of the "history" out of the forwarding table. The 192.* block, and some of the high 190's, look like swamps that are ripe for the picking. Dennis Ferguson