Mark - I agree with you 100% that the Internic had adopted a policy of handing out longer prefixes than I had initially warned everyone Sprint would be refusing to accept from external neighbours. I also note that the Internic also had wording which pointed out the dangers of accepting this sort of prefix from them, right on its application form, which I reproduce below. I think that the InterNIC did its job of warning people of upcoming realities, and therefore its policies were not, in fact, in conflict with ours. 206/8 was specifically chosen, in fact, because no allocations had been made from it at the time. Now, I note that I have pointed out that we are willing to be flexible when it comes to /19s, but for the moment, the filter will reject anything longer than /18s in 206/8 to 239/8. In part this is because it gives me the opportunity to study who has gotten disconnected and how difficult it will be to reconnect them without doubling the number of prefixes we will see in 206/8, not to mention 207/8 to 239/8. You may call it direct engineering terrorism if you like. I call it a sound, planned, well-announced step to keep the maximum growth of the routing tables confined to the level at which technology exists to support them. My only (large) regret is that any long prefixes in 206/8 ever worked at all, principally due to an oversight in a reconfiguration of ICM AS 1800. I hate breaking things that were already working... To translate that sentence: "Maybe. Let's see how bad the mess is first." Sean. - -- from ftp://rs.internic.net/templates/internet-number-template.txt Due to technical and implementation constraints on the Internet routing system and the possibility of routing overload, certain policies may need to be enforced by the major transit providers in order to reduce the number of globally advertised routes. These potential policies may include setting limits on the size of CIDR prefixes added to the routing tables, filtering of non-aggregated routes, etc. Therefore, addresses obtained directly from the InterNIC (non-provider-based, also known as portable) are not guaranteed to be routable on the Internet. ^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
I also note that the Internic also had wording which pointed out the dangers of accepting this sort of prefix from them, right on its application form, which I reproduce below.
Are you certain that the form you cut that sentence from existed before any 206 nets were handed out? Are you certain that everyone who applied for, and got a block like 206/19, used that form?
In part this is because it gives me the opportunity to study who has gotten disconnected and how difficult it will be to reconnect them
The Internet is no longer an experiment. You can more easily see who will be affected if they are on-line. Or are you waiting for the cards and letters to come pouring in?
"Maybe. Let's see how bad the mess is first."
By initially routing long prefixes in 206 you are the ones who have created the mess. So, you made a mistake. Move on higher up the chain and try again. Cutting off companies retroactively is not the answer. You need to put filters in that cut no one off today, but protect against growth tomorrow. -mark
By initially routing long prefixes in 206 you are the ones who have created the mess. So, you made a mistake. Move on higher up the chain and try again. Cutting off companies retroactively is not the answer. You need to put filters in that cut no one off today, but protect against growth tomorrow.
Did the threat of charging for domain names stop people from registering domain names left and right for no apparent reason? No. It seems that the only way for people to pay attention to issues like this is to have it start affecting them one day. Then they start paying attention to the problem, and work to correct it. Sean is willing to correct connectivity problems on a case by case basis, as he has mentioned in a number of his messages. He is willing to accept "cards and letters" in the form of trouble tickets, and deal with the issues. I consider this sufficient. Dave -- Dave Siegel President, RTD Systems & Networking, Inc. (520)318-0696 Systems Consultant -- Unix, LANs, WANs, Cisco dsiegel@rtd.com User Tracking & Acctg -- "Written by an ISP, http://www.rtd.com/ for an ISP."
participants (3)
-
Dave Siegel -
Mark Kent -
Sean Doran