Re: Policy Statement on Address Space Allocations
" The InterNIC allocates addresses to ISPs based on the slow start procedure as detailed in the ISP guidelines. Please utilize the /19, once you have reassigned the /19 and SWIPped them you may request additional address space and if the InterNIC feels you are assigning them efficiently you may request additional address space."
Because of this policy ISP's should start getting allocations from the InterNIC as soon as possible. If you get allocations from another provider, you don't gain any history with the InterNIC. All of that history goes to the provider's allocations, not yours. When you outgrow a provider (and the provider's provider), and later go to the InterNIC, you start over again with 'slow start.' I made this mistake, and it has cost me dearly over the years. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
" The InterNIC allocates addresses to ISPs based on the slow start procedure as detailed in the ISP guidelines. Please utilize the /19, once you have reassigned the /19 and SWIPped them you may request additional address space and if the InterNIC feels you are assigning them efficiently you may request additional address space."
Because of this policy ISP's should start getting allocations from the InterNIC as soon as possible. If you get allocations from another provider, you don't gain any history with the InterNIC. All of that history goes to the provider's allocations, not yours. When you outgrow a provider (and the provider's provider), and later go to the InterNIC, you start over again with 'slow start.'
Now, in various areas, I know that the NIC's procedures have changed over time. And I'm not talking about IP address space here, but wrt domain name allocations. But my experience was different recently. I found that the NIC (aka Kim) was willing to look at our allocation of a /19 from an old provider's space (in 205/8, so it was routable to Sprint). What caused problems for us is that we didn't SWIP it out as we allocated it, but instead SWIPped it out right before going to the NIC. I can't speak for any other cases, though. We went into fairly detailed justification for getting address space from the NIC, and ultimately got a 2-week turnaround time, which was much better than I had been lead to believe by others that it woud be. Along the way, it was made clear that the NIC wasn't interested in Sprint's filtering policies and would not make allocations based on it. Avi
Avi Freedman writes:
Along the way, it was made clear that the NIC wasn't interested in Sprint's filtering policies and would not make allocations based on it.
And well they should not be. As someone said earlier in this thread: Sprint != Internet Fortunately... Alec -- +------------------------------------+--------------------------------------+ |Alec Peterson - chuckie@panix.com | Panix Public Access UNIX and Internet| |Network Administrator | New York City, NY | +------------------------------------+--------------------------------------+
Avi Freedman writes:
Along the way, it was made clear that the NIC wasn't interested in Sprint's filtering policies and would not make allocations based on it.
I'm just a country network jockey and don't understand all this stuff, but Avi's comment is a perfect lead-in ... What's been bothering me is that Sprint is filtering at /19 in 206/8 but just allocated me a /21 out of 206/8. Since my largest customer is leaning on me to multi-home, and since I view Sprint's filtering as indicative of what others are likely to do RSN, I begged Sprint to allocate a block the size of the smallest block they would route if I had gotten it from another NSP. Is it unfair to ask Sprint to make allocations based on its own filtering policies? When I multihome and Pennsauken is down, will Sprint's filtering cut me off from access to other Sprint customers via my alternative path? -- Dick St.Peters, Gatekeeper, Pearly Gateway, Ballston Spa, NY stpeters@NetHeaven.com Owner/operator, NetHeaven 518-885-1295/1-800-910-6671 Internet for Albany/Saratoga, Glens Falls, North Creek, & Lake Placid Visit the Internet Conference Calendar http://calendar.com/conferences
Dick says (with a smile):
I'm just a country network jockey and don't understand all this stuff,
Here is a very simple explanation for you to "take to the bank"; and I'll avoid discussing any particular provider and look at the generic question only. First, pull up your favorite browser and look at this simple diagram from an excellent 1977 paper by Kleinrock and Kamoun [1]: http://www.silkroad.com/public/K&K-ComputerNetworks-77-fig-1.gif Now, consider this model a very simplified model of the Internet. Notice that for purposes of discussion, K&K used a 3-level clustered 24-node network; but the theory scales upward. In fact, image that YOU are a provider at the 3rd level of the network and that the network is expanding rapidly and your routing tables are about to overflow. What must you do to remain at your place in the hierarchy? One obvious way is to create more clusters of route aggregation and form another level in the hierarchy and the 3-level clustered model becomes a 4-level cluster. Without getting into the details, even us Tulane 'bare-foot country networkers :-) " can see that the optimal goal of a provider at each layer is to accept routing information from networks that are only 1 level less than their position in the hierarchy. Of course, there are numerous other variations to the them, but the end results are basically the same. To illustrate this, please take a final browse at another figure from Kleinrock and Kamoun [1]: http://www.silkroad.com/public/K&K-ComputerNetworks-77-fig-2.gif This diagram is just K&K figure 1 illustrated in a tree. As a side note, please understand that hierarchical routing is not a new concept. In fact the original concept of classful A, B, and C IP address space was basically the same model, where individual clusters in the network were originally either a /8 or a /16 or a /24; and the network was somewhat simpler and more closely resembled a symmetric model. Back to Fig. 2; please note that with the implementation of classless address space, the model becomes much more complex and a drawing of the Internet is much more complex; but what remains the same is the fact that as the network grows, you can easily understand (and think for yourself) why certain providers have particular business policies for connecting to their network or why "things are the way they are", in a simple matter of speaking. Furthermore, providers that the highest levels of the hierarchy have a very difficult task considering that they did not have the privilege to manage the address space in the during the early days of the Internet. In fact, as many people know, many remain incredulous to the fact that the original funding agency may have mismanaged the commercialization of the original IP network (but I'll omit the details). Understandably, it was difficult to take the fragmented IP address space model and create an environment that would allow an easy transition from a non-commercial use policy to uncontrollable commercial growth. But, on the other hand, taking a "hands off, anything goes, turn the keys over to commercial providers" approach...... I think historians will find that the study of this transition and the subsequent business climate and problems very interesting (as the concept of hierarchical routing becomes second nature to the layman). I would like to acknowledge the members of the CIRD-WG within the IETF for pointing me into the direction of the archives of Computer Networks and in particular the papers of K&K, with special thanks to Noel Chiappa for the pointer and UCLA for a copy of the original Kleinrock paper. In addition, in respect to one of the authors, Professor Kleinrock, I would like to say thank you for such outstanding work in the field. I look forward to your 1996 publications of _Queuing Systems_ by John Wiley and Sons. Also, thank you for your patience with my use of the southern vernacular. Best Regards Tim [1] Kleinrock, L. and Kamoun, F., "Hierarchical Routing for Large Networks", Computer Networks, Vol 1, No. 3, 1977, p. 155-174. +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... images are the literature | | The Silk Road Group, Ltd. | of the layman." | | | | | http://www.silkroad.com/ | Umberto Eco | | | | +------------------------------------------------------------------------+
Footnote to last post with refs and gifs: The oversimplified statement below:
........................ can see that the optimal goal of a provider at each layer is to accept routing information from networks that are only 1 level less than their position in the hierarchy. Of course, there are numerous other variations to the them, but the end results are basically the same.
Please keep in mind, that routing information also must be shared with peer networks at the higher levels as well. The point of the discussion is not to specify all requirements of peer-to-peer routing; but only to point out, in a simple model the basics of hierarchical routing to the layman. (and try to keep an eye on the SuperBowl, BTW....) Also as a footnote, please keep in mind that targeting specific ISPs for routing policy issues is problematic because SOMEONE (ie. at the upper level of the hierarchical model) has to carry the "load" for all the grand-fathered and fragmented address space (which BTW they have little tangible control). It is a difficult job given that the ISPs have little choice in alternative routing protocols and their tool kit is bare (presently). Also keep in mind, however, that to advocate CIDR or CIDR like routing policy and support the development of NATs and DHCP and then show emotion when incredulous engineers point out the problems with this approach by stating that "we do not have an implementable solution" is a bit of irony; for the simple reason that just as we do not have workable alternatives for IP hierarchical routing, the same holds true for NAT, DHCP, and numerous other proposals and technical details to "fix" the problem, but the overall direction and momentum of the current track is clear by the actions of the WGs and inactivity of others. <IRONY> Finally, one obvious way to solve the problem that would create much controversy with the higher level commercial players is to build another large aggregate provider(s) at the top of the hierarchy with a very rigid set of constraints and move the existing elephants down a level to default status :-) That way the highest level in the hierarchy could remain very very clean and efficient. Plus, in parallel, develop a much more fair and efficient policy of address space allocation (which BTW, I have no suggestion or solution to offer either). The idea, of course, only works in theory and on paper, because of commercial constraints and interests. </IRONY> Best Regards, Tim +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "Every decoding is another | | The Silk Road Group, Ltd. | encoding.." | | | | | http://www.silkroad.com/ | David Lodge | | | | +------------------------------------------------------------------------+
" The InterNIC allocates addresses to ISPs based on the slow start procedure as detailed in the ISP guidelines. Please utilize the /19, once you have reassigned the /19 and SWIPped them you may request additional address space and if the InterNIC feels you are assigning them efficiently you may request additional address space."
Because of this policy ISP's should start getting allocations from the InterNIC as soon as possible. If you get allocations from another provider, you don't gain any history with the InterNIC. All of that history goes to the provider's allocations, not yours. When you outgrow a provider (and the provider's provider), and later go to the InterNIC, you start over again with 'slow start.'
No, this isn't necessarily true. Many providers assume that just because they received a /19 or whatever from its upstream ISP they will automatically receive a larger block from the InterNIC with no questions asked. ISPs must show they've utilized any previously allocated blocks (whether from the InterNIC or from its upstream) efficiently to receive additional addresses. Once they do this than there's no problem receiving additional space. If they have not shown proper utilization than in some cases they will receive a smaller block to start. Kim
I made this mistake, and it has cost me dearly over the years. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation
participants (6)
-
Alec H. Peterson
-
Avi Freedman
-
Dick St.Peters
-
Kim Hubbard
-
Sean Donelan
-
Tim Bass