See www.liszt.com ---------- Od: Phil Howard[SMTP:phil@charon.milepost.com] Odesláno: 9. září 1997 15:15 Komu: Michael Dillon Kopie: nanog@merit.edu Předmět: Re: too many routes Michael Dillon writes...
I would think the latter. If so, would anyone know why it is that the backbone providers are so resistant to giving out blocks to do this?
If backbone operators do not efficiently allocate IP space to their downstream customers then the next time they need additional IP space they will not be able to get any. Everyone in the food chain has to operate under the same policies of justifying IP space based on need and using the space efficiently. There is more info on this at http://www.arin.net and in particular you should have a look through the recommended reading section especially any documents relating to CIDR.
It seems that efficiency is measured only in terms of numbers of IP addresses and disregards numbers of routes. We are at a point that we can pretty much nearly fill a /19 and will be past that point by the end of the year. Beyond that, I would think that when we need to keep coming back for address space, we would do it in increments of /19. How much of the routing space is filled with networks smaller than /19 that are part of an ASN that has enough other smaller networks to renumber into a single /19. I'm wondering if the policies are not being counter productive due to the apparently opposing nature of IP space vs route space (e.g. the one where people have to take more IP space to be routed, because of route filters, because of too many routes, because IP space is so fragmented, because IP space needs to be conserved, because everyone needs to get more IP space, becayse of route filtering, because of so many routes, because ...). I was given some other mailing lists for dealing with those issues by someone. I'll be subscribing there. In the mean time, especially to help put topics on the correct mailing list (if on-topic posts are to be another goal) can someone post an informatory posting that lists ALL the mailing lists (preferrably with a brief summary of topic/purpose) that would be of interest to ALL the aspects of network provider business and operation? Or is this listed on a web page? If not, I'll offer to host just such a web page if I can get a pretty much complete list (I'll even write HTML to get it going). But I'm sure most everyone here has some access to some web space somewhere. -- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
The routes issue historically comes down to the fact that Sprint did not want to convert from Cisco 4000 to Ciscos that had larger memory capacity. Memory is cheap these days ... the big boys just don't wish to have a free market. Deny /19s and or a transition to IPNG then deny Peering to keep the market from being open. Hey folks, it is not closed. Keep the faith and let the big boy bleed market share. I would hope that ARIN, RIPE, and APNIC would have the guts to keep giving routable blocks to new contenders. Please people, we must stop abstructions to keep the market open and competitive. --- On Wed, 10 Sep 1997 08:54:08 +-200 Jan Novak <jan.novak@aliatel.cz> wrote:
How much of the routing space is filled with networks smaller than /19 that are part of an ASN that has enough other smaller networks to renumber into a single /19.
I'm wondering if the policies are not being counter productive due to the apparently opposing nature of IP space vs route space (e.g. the one where people have to take more IP space to be routed, because of route filters, because of too many routes, because IP space is so fragmented, because IP space needs to be conserved, because everyone needs to get more IP space, becayse of route filtering, because of so many routes, because ...).
I was given some other mailing lists for dealing with those issues by someone. I'll be subscribing there.
In the mean time, especially to help put topics on the correct mailing list (if on-topic posts are to be another goal) can someone post an informatory posting that lists ALL the mailing lists (preferrably with a brief summary of topic/purpose) that would be of interest to ALL the aspects of network provider business and operation?
Or is this listed on a web page? If not, I'll offer to host just such a web page if I can get a pretty much complete list (I'll even write HTML to get it going). But I'm sure most everyone here has some access to some web space somewhere.
-- Phil Howard KA9WGN +-------------------------------------------------------+ Linux Consultant | Linux installation, configuration, administration, | Milepost Services | monitoring, maintenance, and diagnostic services. | phil at milepost.com +-------------------------------------------------------+
---------------End of Original Message----------------- -- From: Joseph T. Klein, Titania Corporation http://www.titania.net mailto:jtk@titania.net Sent: 02:34:40 CST/CDT 09/10/97 If the Internet stumbles, it will not be because we lack for technology, vision, or motivation. It will be because we cannot set a direction and march collectively into the future. -- http://info.isoc.org/internet-history/#Future
On Wed, 10 Sep 1997, Joseph T. Klein wrote:
The routes issue historically comes down to the fact that Sprint did not want to convert from Cisco 4000 to Ciscos that had larger memory capacity. Memory is cheap these days ... the big boys just don't wish to have a free market.
I do not think sprint had 4000s in their backbone, they had AGS+ routers. The problem is not the lack of memory, but that the CPU can not process all the date in the memory when it needs to. The cisco 7500 have that same prob, sure you can put 256 megs of RAM in them, but can the CPU recalculate the next hop if most of that date in that RAM changes? The new RSP4 card may have solved that, we may be at a point now where the router has enough processor to be able to process all the data it has stored in memory and do it quickly. Nathan Stratton President, CTO, NetRail,Inc. ------------------------------------------------------------------------ Phone (888)NetRail NetRail, Inc. Fax (404)522-1939 230 Peachtree Suite 500 WWW http://www.netrail.net/ Atlanta, GA 30303 ------------------------------------------------------------------------ "No king is saved by the size of his army; no warrior escapes by his great strength. - Psalm 33:16
On Wed, 10 Sep 1997, Joseph T. Klein wrote:
The routes issue historically comes down to the fact that Sprint did not want to convert from Cisco 4000 to Ciscos that had larger memory capacity. Memory is cheap these days ... the big boys just don't wish to have a free market.
I do not think sprint had 4000s in their backbone, they had AGS+ routers. The problem is not the lack of memory, but that the CPU can not process all the date in the memory when it needs to. The cisco 7500 have that same prob, sure you can put 256 megs of RAM in them, but can the CPU recalculate the next hop if most of that date in that RAM changes? The new RSP4 card may have solved that, we may be at a point now where the router has enough processor to be able to process all the data it has stored in memory and do it quickly.
AGS+'s only could handle 16meg, the cpu in a AGS+ is the same as in a 7000 series, (motorola 68040) As of a year ago, I believe I heard that sprint still had AGS+'s in their backbone and were upgrading them to 7000 series equipment. -- Jason Jason Vanick ------------------------------------------ jvanick@megsinet.net Network Operations Manager V: 312-245-9015 MegsInet, Inc. 225 West Ohio St. Suite #400 Chicago, Il 60610
Having hopelessly screwed up my facts ... I was trying to make a point here. So the router was worse than I thought. Retaing policies that exclude new players because of AGS+'s inability to handle large routing flaps just does not cut it. Sprint imposed this at a time when 7000s with 64M of memory where available. Will /19 remain policy when the majors are running with Cisco 12000 and GRFs? The CPU issue has more to do with changes in the routing table rather than the size. Aggrigation is good because if properly implemented it reduces router flaps. If aggregation is the goal then mechanisms should be developed for exchanging CIDR blocks so the address space can be re-packed. The /19 policy is archaic. It creates an obstacles and only partly resolves the problem. Fixing holes in CIDR blocks, exchanging fragmented blocks for contiguous blocks, and cleaning up "The Swamp" can do more for the stability and size of the routing table. BTW - If you use a route server to do the dampening and calculation of peer routes you can even make a wimpy CPUed 7000 handle backbone traffic. --- On Wed, 10 Sep 1997 10:03:07 -0500 (CDT) Jason Vanick <jvanick@megsinet.net> wrote:
On Wed, 10 Sep 1997, Joseph T. Klein wrote:
The routes issue historically comes down to the fact that Sprint did not want to convert from Cisco 4000 to Ciscos that had larger memory capacity. Memory is cheap these days ... the big boys just don't wish to have a free market.
I do not think sprint had 4000s in their backbone, they had AGS+ routers. The problem is not the lack of memory, but that the CPU can not process all the date in the memory when it needs to. The cisco 7500 have that same prob, sure you can put 256 megs of RAM in them, but can the CPU recalculate the next hop if most of that date in that RAM changes? The new RSP4 card may have solved that, we may be at a point now where the router has enough processor to be able to process all the data it has stored in memory and do it quickly.
AGS+'s only could handle 16meg, the cpu in a AGS+ is the same as in a 7000 series, (motorola 68040) As of a year ago, I believe I heard that sprint still had AGS+'s in their backbone and were upgrading them to 7000 series equipment.
-- Jason Jason Vanick ------------------------------------------ jvanick@megsinet.net Network Operations Manager V: 312-245-9015 MegsInet, Inc. 225 West Ohio St. Suite #400 Chicago, Il 60610
---------------End of Original Message----------------- -- From: Joseph T. Klein, Titania Corporation http://www.titania.net mailto:jtk@titania.net Sent: 11:39:32 CST/CDT 09/10/97 If the Internet stumbles, it will not be because we lack for technology, vision, or motivation. It will be because we cannot set a direction and march collectively into the future. -- http://info.isoc.org/internet-history/#Future
On Wed, 10 Sep 1997, Joseph T. Klein wrote:
Having hopelessly screwed up my facts ... I was trying to make a point here. So the router was worse than I thought. Retaing policies that exclude new players because of AGS+'s inability to handle large routing flaps just does not cut it.
Sprint imposed this at a time when 7000s with 64M of memory where available. Will /19 remain policy when the majors are running with Cisco 12000 and GRFs?
Lots of stuff cut out.
BTW - If you use a route server to do the dampening and calculation of peer routes you can even make a wimpy CPUed 7000 handle backbone traffic.
This is what I beleave sprint is doing. They are using the new Cisco 12000 GSR with external router servers. It is a smart way of patching the problem. If you need more CPU or memory you can just add a bigger box and more RAM. Nathan Stratton President, CTO, NetRail,Inc. ------------------------------------------------------------------------ Phone (888)NetRail NetRail, Inc. Fax (404)522-1939 230 Peachtree Suite 500 WWW http://www.netrail.net/ Atlanta, GA 30303 ------------------------------------------------------------------------ "No king is saved by the size of his army; no warrior escapes by his great strength. - Psalm 33:16
On Wed, 10 Sep 1997, Joseph T. Klein wrote:
Having hopelessly screwed up my facts ... I was trying to make a point here. So the router was worse than I thought. Retaing policies that exclude new players because of AGS+'s inability to handle large routing flaps just does not cut it.
Sprint imposed this at a time when 7000s with 64M of memory where available. Will /19 remain policy when the majors are running with Cisco 12000 and GRFs?
The CPU issue has more to do with changes in the routing table rather than the size. Aggrigation is good because if properly implemented it reduces router flaps. If aggregation is the goal then mechanisms should be developed for exchanging CIDR blocks so the address space can be re-packed.
The /19 policy is archaic. It creates an obstacles and only partly resolves the problem. Fixing holes in CIDR blocks, exchanging fragmented blocks for contiguous blocks, and cleaning up "The Swamp" can do more for the stability and size of the routing table.
BTW - If you use a route server to do the dampening and calculation of peer routes you can even make a wimpy CPUed 7000 handle backbone traffic.
When the class A's are chopped up into CIDR blocks, the number of routes in the backbone routing tables will dramatically increase, even if all of them are /19 or larger. Saying that instead of filtering routes Sprint should have just waited for everyone to clean up the routes as you suggest seems silly -- they did what they had to do to keep their network operational. They can't afford to rely on other people cleaning up their mess. I am not sure what policies you think should be there that aren't -- we are renumbering existing blocks into our own /18, and will be returning those blocks to our upstream providers. They get the benefit of having their address space back, our aggregates drop in half, and we get the benefit of the full use of our multiple connections. I don't see a problem with that, and there was no difficulty getting the address space telling them what we were going to do. John Tamplin Traveller Information Services jat@Traveller.COM 2104 West Ferry Way 205/883-4233x7007 Huntsville, AL 35801
participants (5)
-
jan.novak＠aliatel.cz -
John A. Tamplin -
Joseph T. Klein -
jvanick＠megsinet.net -
Nathan Stratton