John - Like many others here and in private email, you make excellent points, and were influential in helping move towards allowing /19s in 206/8 on the grounds that many people honestly (mis-)understood comments about indecision with respect to /19s vs /18s and noises about possibly re-evaluating things in the future to be a guarantee of routability of /19s in the 206/8 range. I also agree with your points that encouraging the growth in the number of providers, particularly small providers, is very important to the evolution of the ubiquitous Internet, and that anything that holds back the growth of the number of small and mid-size providers should be avoided. Unfortunately, I don't think that we can adopt a policy of "should be avoided at all costs", because one such cost is having large segments of the Internet stop working. Consequently, there are a number of people at work on preventing further increases in the size of routing tables. While I do agree with Dave Crocker et al. that strict nonportable address allocation does make it difficult for small and mid-size providers to change connectivity to some degree, I believe that for the moment this is unavoidable, no matter that I wish that it was, or that I could put some of my efforts off any longer than I already have. However, with respect to the difficulties that inflexible minimum sizes on portable allocations (i.e., those that are likely to be routable throughout the entire Internet) and limits on routability of long prefixes, most things would be made much easier on small and mid-size providers if sufficiently good renumbering technology existed for small-i internets. Therefore I make the economic argument to workstation, operating-system and router vendors that it is in their interests to develop easy-to-use or (semi-) automatic renumbering tools for all their products, and to participate in the development of protocols that allow these tools to cooperate in the process of renumbering even sizeable small-i internets. I assert (wearing a price-theorist's hat) that such a technology will lower the costs of providing big-I Internet services significantly, and that this cost-savings will allow for a reduction in pricing due to competitive pressures, and, caeteris paribus, will lead to further growth of the Internet and consequently more sales of "Internet-ready" workstations, operating-systems, and routers. Sean. - -- Sean Doran <smd@sprint.net>
I have a couple of phone lines at home, I use different long distance carriers on them, and I like it that way, so that if either Sprint or ATT or MCI fail, I have a backup choice of just picking up another phone. If I understand John's argument right, he is playing the same game by having multiple service providers, presumably at his extra cost, using them as backup for each other. Sounds like a good idea to me, especially given the lousy quality of the network at large that I hear complaints about from people all over the country lately (someone should do a survey with end users to qualify this). He does not want to renumber every time this Sprint routing loop appears (or whatever problems any of the providers may have). He just wants enough flexibility to attain the services he needs. Well, the CIDR stuff was kind of neat, as it helped prolonging the current addressing agony, but have we really taken the next steps (short of saying there will be more bits to confuse routers with in the future)? CIDR may actually be more useful in areas with less competition and less AS diameter. CIDR clearly can work well in a backbone-regional-campus, or a PTT-client, or so, model. It works less well of there are more mesh-demanding levels (like some edge service providers needing redundancy with their long distance ISPs that operate on their behalf). This is not a protocol problem, it is an administrative and architectural problem of how to design a system that accomodates the needs of at least 95% of the Internet clients at a satisfaction level above the 95th percentile. It is not clear to me whether anyone is really working on that (I think NANOG and the IEPG should). That will have to accomodate "lower level" service providers (as well as end sites) to have robust and redundant interconnections with multiple service providers. Once you provide dial-tone percentile levels of services, they may go back to a single service provider. Until then... I know you know all this, but I thought I throw it in anyway.
participants (2)
-
hwb＠upeksa.sdsc.edu -
Sean Doran