Re: Policy Statement on Address Space Allocations
| Now can we try to make things work rather than point fingers! Yes, indeed; that is the ultimate goal we share. We just have some differences of philosophy -- you think that RIPE really can persuade people into having only 1024 announements (preferably far fewer) in 195/8, and I don't. That's all. The compromise we could find would involve a practicable method by which we don't have to put a prefix-length-floor in place, but at the same time don't have to spend enormous amounts of (unavailable) CPU time filtering based on what's in the RIPE database. Avoiding large amounts of (largely unavailable) staff time at Sprint and RIPE to chase down offenders and try to figure out how to stop them from ignoring their contribution to melting routers is also something I'd like to avoid. I don't love my solution either, but it does have the advantages of being CPU inexpensive, does a reasonable job of guaranteeing an absolute maximum number of prefixes in 195/8 (the sum of the /18s, /17s, /16s ... /7s and the /8 itself) even in the worst case, and provides what has already proven in practice to be a tractable enforcement mechanism. I regret the renumberings which have happened as a result, but unfortunately people are still being hooked up to the network with freshly-allocated PI /23s and /21s, and only after they actually try to use them does it click that they really won't work. Moreover, when these people try to find out why things aren't working, (and sometimes after trying various so-far unsuccessful means to have an exception made), they often understand what's happening in core routers and from then on have tended to do a good job of not introducing new prefixes into the core. I am aware of various disclaimers and warnings the registries issue and I'm grateful for them, actually. They've been helpful. Some folks at a couple of our peers/competitors have also been good at protecting their customers by telling them a great deal about CIDR and PI vs PA space. The large failing of CIDRD and the CIDR effort is one of being unable to communicate things to precisely these people receiving new allocations, which in large part is due to the inability to get any documents published. So, as a consequence of some parties being religiously opposed to issuing documents emanating from a part of the IETF that describe what really is happening now -- in order to save newcomers and folks who haven't followed CIDRD a great deal of confusion and effort -- on the grounds that any such publication would look like the IETF "endorsing" some evil greedy bastards who are out to rape and screw small providers, people in small countries, small animals, or whatever the cause celebre of this type of zealot happens to be today. The people being screwed are those who have no information about how busy routers are and how untenable lots of addresses of any nature are, and how important aggregation is, and therefore how good PA addresses are to them *until* they run right smack into my filters. The campaign of "keep them ignorant to force providers to abandon this silly notion that currently available routers are too busy to deal with as many unaggregated addresses as people want to present to them" only succeeds in *hurting* small providers and startup providers. And those small providers are who pay my salary, and you better believe that my colleagues and I are very keen on keeping them in business and seeing their customer base and income grow substantially, so that they end up buying more and bigger circuits -- both Internet connections and raw private lines and international private lines -- and keep being able to pay for them for a very very very long time. Sean.
Sean Doran <smd@cesium.clock.org> writes:
| Now can we try to make things work rather than point fingers!
Yes, indeed; that is the ultimate goal we share.
Pooooh .... relief.
We just have some differences of philosophy -- you think that RIPE really can persuade people into having only 1024 announements (preferably far fewer) in 195/8, and I don't. That's all.
OK. I call this a challenge but you won't let me try ;-).
The compromise we could find would involve a practicable method by which we don't have to put a prefix-length-floor in place, but at the same time don't have to spend enormous amounts of (unavailable) CPU time filtering based on what's in the RIPE database.
All I am suggesting is to set it at /19 initially which should consume roughly ;-) as many CPU time as setting it to /18. Should we fail to meet the challenge later, I suggest to set it to /18 and allow some /19 exceptions caused by our allocation policy. This will be a quite limited number, the information will be machine readable in real time. We will provide the tools (3 lines perl) to generate filters from it. Frankly: If you cannot do this your motives become quite questionable.
Avoiding large amounts of (largely unavailable) staff time at Sprint and RIPE to chase down offenders and try to figure out how to stop them from ignoring their contribution to melting routers is also something I'd like to avoid.
It is not as big a deal as you want to make it. Daniel
I thought it's time for the InterNIC to join in on the fun :-) The registries (although I shouldn't speak for all of them) would be more than happy to allocate address space in whatever way the ISPs agree is the "right way". The problem is, you can't agree on what's the "right way" of doing it. Everyone has their own agenda and most have a very limited view of what's best, meaning their view is limited to their own requirements. On the other hand, the registries must try and take into consideration everyone's agenda and needs. This is not an easy task. The InterNIC is very aware of the routing table problem. We do everything humanly possible to educate everyone requesting address space about this. We also refer everyone to their upstream provider in an effort to help with this problem. The truth is, Sprintlinks filtering policy has helped because in the past we could only threaten people with the possibility of what might happen. Now we can point to facts rather than supposition. People are listening and they are going to their ISP for address space. We have dropped from about 800 /24s - /21 assignments per month to about 30 /24s - /21s per month. However, it isn't so easy to convince ISPs to contact upstream providers for address space. Understandably, they all want portable address space. They do not want to be tied to their upstream ISP. David Conrad mentioned that the InterNIC receives about 20 templates per week from startup ISPs, the number is now closer to 50. Most I refer to their upstream but they are not happy about it. True, the registries do work hard to help preserve the address space. I don't know what the growth rate of new ISPs in other areas is, but in North America it seems to be the newest fad. The InterNIC receives many calls each day from people who have decided to become ISPs, the only problem is that many don't know how to spell TCP/IP. Now if we were to issue every ISP a first allocation of a /18 prefix or shorter - how long do you think the address space will last. I know that the routing table problem is a more pressing issue, however, I believe if we drastically change the allocation policy and give a /17 to each ISP regardless of their requirement that will quickly change. Most of you honestly believe you need a huge amount of space for growth, well what makes you any different from every other ISP on the planet. If you didn't believe in yourself or your potential, you wouldn't be in this business. However, realistically, we cannot give everyone the amount of address space that he/she wants to start - that's why we have slow-start, to help determine what an ISP actually needs. And for the record, the InterNIC does make many allocations from larger reserved blocks. Now, I'm sure that every ISP reading this message cares very deeply for the Internet (as does the InterNIC) and utilizes address space efficiently, etc. But consider the hundreds of ISPs that don't. Kim
[ ... ] Someone summarizes:
Now, I'm sure that every ISP reading this message cares very deeply for the Internet (as does the InterNIC) and utilizes address space efficiently, etc. But consider the hundreds of ISPs that don't.
Sorry, but here we go again, back to playing on emotions and guilt. " .... cares very deeply for the Internet..... " Just because a start-up ISP desires portable address space and does not want to be dependent on a up-stream service provider does not translate to the emotional position.... " .... don't care very deeply for the Internet..... " The natural direction of a conversation that has sunk to this level is to degrade to name calling, slander, and high emotional feelings. PLEASE do not degenerate this conversation to this level. It is not a "good and evil" "care and don't care" "black and white" issue. Just because ISPs (whom ever they are and where ever they many live) disagree with the up-stream, provider based world that the world has created, their rights, opinions and ideas should be respected. If there are real 'demons' in the world, it is when issues, ideas, and opinions are reduced to 'black and white', 'good and bad' ' you are right and she is wrong' oversimplifications that serve only to mask the real issues. { and then ... there are those in the world who enjoy that tact as well } Take care, Tim +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... images are the literature | | The Silk Road Group, Ltd. | of the layman." | | | | | http://www.silkroad.com/ | Umberto Eco | | | | +------------------------------------------------------------------------+
This is great, I feel like one of the in crowd - getting slammed by Tim Bass :-) Seriously, I wasn't trying to put it on an emotional level - just trying to point out some basic issues that haven't been mentioned. Sometimes you have to do what's best for the Internet as a whole while not necessarily what's best for you personally. Some are willing to do this and some aren't. Also, I wasn't referring to the ISPs that want portable address space. As I stated in the message I understand why ISPs don't want to be dependant upon their upstream providers. Kim
[ ... ]
Someone summarizes:
Now, I'm sure that every ISP reading this message cares very deeply for the Internet (as does the InterNIC) and utilizes address space efficiently, etc. But consider the hundreds of ISPs that don't.
Sorry, but here we go again, back to playing on emotions and guilt.
" .... cares very deeply for the Internet..... "
Just because a start-up ISP desires portable address space and does not want to be dependent on a up-stream service provider does not translate to the emotional position....
" .... don't care very deeply for the Internet..... "
The natural direction of a conversation that has sunk to this level is to degrade to name calling, slander, and high emotional feelings.
PLEASE do not degenerate this conversation to this level. It is not a "good and evil" "care and don't care" "black and white" issue. Just because ISPs (whom ever they are and where ever they many live) disagree with the up-stream, provider based world that the world has created, their rights, opinions and ideas should be respected.
If there are real 'demons' in the world, it is when issues, ideas, and opinions are reduced to 'black and white', 'good and bad' ' you are right and she is wrong' oversimplifications that serve only to mask the real issues.
{ and then ... there are those in the world who enjoy that tact as well }
Take care,
Tim
+------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... images are the literature | | The Silk Road Group, Ltd. | of the layman." | | | | | http://www.silkroad.com/ | Umberto Eco | | | | +------------------------------------------------------------------------+
This is great, I feel like one of the in crowd - getting slammed by Tim Bass :-)
Consider it your lucky day :-) Did you find a four leaf clover after the snow melted, or find a lucky horse-shoe in the fields today? Seriously, There are better ways to promote CIDR hierarchical routing without the " they don't care about the Internet" rhetoric, and to ask you not to resort to it is not a "slam", sorry to make you feel that way. (and BTW, it is not the first time the request has been made...) There are at least five hierarchical routing architectures that are not CIDR based that would greatly reduce the administrative problems the InterNIC and RIPE (and the rest of the world) if they were not tabled in favor of the current path we walk. Okay, granted, we walk the CIDR path today. Fine, CIDR has done a good job putting a band-aid on a flying elephant, we all agree. What is hard to understand is why men and women with intelligent brains believe that there is only ' one way, one religion' to do hierarchical routing. Why try to convince the world that there is? Interesting enough, after spending days and days in the journal archives most major journals and finding only one author's name that is a part of these discussions in any peer reviewed publication, is very enlightening. I am quite sure that the most vocal advocates of CIDR have read very little historical documents outside of the IETF RFCs. I highly recommend some time spent in review of the principals of hierarchical routing; graph theory; queuing systems; dynamic programming and others as well as the marginalia of journal articles on the subject. For those who do, I will be very surprised to learn that the "emotional plea for CIDR or die" remains at their fingertips; and phrases like " he or she does not care about the Internet....". Question: What did those in the Dark Middle Ages do when branded a heretic by the religious zealots ? Answer: Most of them were put to the flame and ridiculed. Very truly yours, Tim +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "Every decoding is another | | The Silk Road Group, Ltd. | encoding.." | | | | | http://www.silkroad.com/ | David Lodge | | | | +------------------------------------------------------------------------+
Tim, What is hard to understand is why men and women with intelligent brains believe that there is only ' one way, one religion' to do hierarchical routing. What's REALLY hard to believe is that we STILL haven't gotten through to you. No one is telling you that there is one way and one religion. That's what you, in your conspiracy theory, would like to believe, but it's simply NOT true. We are quite certain that there ARE other ways of doing routing. But they are not yet implementable. There is a LOT of work to be done to bring a new routing architecture to full deployment. It has not happened yet. You would be much better served by spending the time to refine and bring one of these to implementability than you will by continuing to stand up and say that we refuse to listen to you. I apologize for repeating myself, but we would love to have something better. Until such an architecture gets sufficiently refined that it can migrate from theoretical journals (or, in the case of Nimrod, theoretical Noelgrams ;-) to something that we can actually code up, you should not expect to see any serious interest in implementation. Unlike certain other working groups, if we do not have a working product on time, there are certain extremely serious ramifications. We cannot simply say "stop the Internet while we figure this out". For one, those of us in commercialdom would immediately be in an Unemployment line. ;-) Or the morgue after the user revolt. I strongly encourage you to continue your study of the problem. I further encourage you to participate in the IRTF and with the other routing theorists (you know the group) who are actively interested in these issues. And I further encourage you to take some time to understand the harsh engineering realities that we face. And I finally encourage you to find a better platform for your discussions than these highly inappropriate mailing lists. Back to my code, Tony
Tony kindly responds:
We are quite certain that there ARE other ways of doing routing. But they are not yet implementable. There is a LOT of work to be done to bring a new routing architecture to full deployment. It has not happened yet.
Tony, I respect you and appreciate your statement, but I have scores of email from IETF WGs, such as your excellent group that infer time and time again that there is only CIDR, all other proposals on the table are not implementable. It is nice to know that you believe in your heart otherwise.... thank you. Honestly, I am going to frame your e-mail and put it up in HTML and refer to it :-)
You would be much better served by spending the time to refine and bring one of these to implementability than you will by continuing to stand up and say that we refuse to listen to you.
You are correct! Every time these CIDR problems arise I feel exactly the same way. It warms my heart to see you state in public that your are "quite certain that there ARE other ways"; because based on your last internet-draft and your refusal to address the issue, I was beginning to wonder if bit-slinging was damaging to neurons. Now I feel much better knowing that one of the people that I truly admire understands engineering principles. (and I truly admire what CIDR-WG is doing..... , believe me, and I have stated this before, CIDR is *not* the problem, the problem is that we have *no other alternative*) [ .... deleted perfectly good ideas I completely agree with .... ]
And I further encourage you to take some time to understand the harsh engineering realities that we face.
( this begs an answer ........ sorry not to be brief ) I understand the 'harsh realities' you face well.... the CIDR WG is doing it's best to "keep the plane flying" which translates to "do whatever it takes" to: (1) Minimize routing table growth; (2) Maintain Internet growth; (3) Maintain a full partition-less Internet. Since I have chosen directly and consciously not to be in the ISP business (and for my bank account NOT to depend on Internet growth hardwares sales, services, etc.) objectivity is less biased, IMO. Honestly, I could care less a vendor sold another router or a regional put up another DS3. I do consider, however, that the small business interests of small ISPs are pushed to the side by the zeal for 1, 2, and 3; and based on what I read and hear everyday, the small businesses and start-up ISPs are finding it more difficult to 'play ball' with the up-stream, non-portable aggregation path and the big national ISP polices not to allow the little guys in the NAPS. (yes, the routing table benefit........ but the big fish swallow the little fish to accomplish the goal.... IMO) These are the 'harsh realities" that, from a somewhat non-financial position' are just as important as 1, 2, and 3. Because I believe the the small business paradigm you and a few others enjoy quipping about "conspiracies". Big businesses pushing small businesses out of the circle is not a "conspiracy', Tony. With all due respects, it is just business as usual in the commercial world. I think that I am entitled *not* to enjoy watching small ISPs getting pushed aside... I put up the Linux Benchmark WWW page over a year ago to help small ISPs understand the UNIX power they could get for small money to support the community at my expense, BTW) There are more "harsh realities" than meets the eye. If the Internet believes that 1,2 and 3 are more important than small business opportunity, then that's okay by me. I have only asked that the IETF have a clear policy stating what the "harsh realities" and objectives are. (why not just state it.... is it wrong to speak the 'harsh reality'.... ?) And, I might add, I do feel that it IS appropriate to discuss the lack of policy and objective in this forum. If it was not, then I would not bring the subject up for discussion. It is appropriate and it needs to be addressed BEFORE issuing political drafts, RFCs, and policy statements that are NOT supported by a document which defines the immediate and long term 'harsh realities' of the Internet. If the goals are 1,2, and 3 are paramount and small business access *must* suffer, then it is the IETFs responsibility, IMO, to state the policy clearly and not be overtly driven by commerce. (if I remember correctly, the E stands for engineering not marketing:-) Thanks for your kind reply and the opportunity to reply, Tim +------------------------------------------------------------------------+ | Tim Bass | | | Principal Network Systems Engineer | "... images are the literature | | The Silk Road Group, Ltd. | of the layman." | | | | | http://www.silkroad.com/ | Umberto Eco | | | | +------------------------------------------------------------------------+
We are quite certain that there ARE other ways of doing routing.
It is nice to know that you believe in your heart otherwise.... thank you. You're welcome. Just so no one thinks I've gone completely looney (ok, loonier ;-), I also think that practical and affordable electrical cars, magnetic monopoles, nuclear fusion, superconducting string, and FTL travel also exist. However, I'm not the researcher looking for any of these, either. Nor should the remainder of the IETF. Tony
Kim Hubbard <kimh@internic.net> writes:
Seriously, I wasn't trying to put it on an emotional level - just trying to point out some basic issues that haven't been mentioned.
If Kim only gets half the abuse we are getting when providing registration services to the community I can fuly understand that she can get somewhat emotional "by accident". Daniel
We just have some differences of philosophy -- you think that RIPE really can persuade people into having only 1024 announements (preferably far fewer) in 195/8, and I don't. That's all.
The compromise we could find would involve a practicable method by which we don't have to put a prefix-length-floor in place, but at the same time don't have to spend enormous amounts of (unavailable) CPU time filtering based on what's in the RIPE database.
So how is this for a compromise: If there actually _are_ more announcements than 1024 in any particular /8 under the control of the RIPE NCC, you implement filtering in such a way that it gets down below 1024 again. In this scenario, as long as the NCC can persuade it's customers to aggregate, there are no problems. And if problems arise, it is extremely likely that they can be fixed by filtering /20 and longer. That way, only the offenders suffer and not the people who aggregate as RIPE tells them to do. A weekly check to see if the number of announcements stays below 1024 would be quite adequate and not unduly machine or manpower intensive, in my opinion.
participants (6)
-
Daniel Karrenberg -
Iljitsch van Beijnum -
Kim Hubbard -
Sean Doran -
Tim Bass -
Tony Li