-----Original Message----- From: John M. Brown <jmbrown@ihighway.net> To: nanog@merit.edu <nanog@merit.edu> Date: Sunday, September 13, 1998 4:34 AM Subject: Clean up your annoucements! Re: The Cidr Report
Yup! (I agree with both of your points! :) )
We should allow /24's into the route system and it wouldn't be as big of a deal if folks like AS701 and others cleaned up there routes.
Many rural providers are going to be multi-homing and thus we are going to see an increase of /24 - /20 blocks.
jmbrown@ihighway.net
You mention the "route" system. Many people feel that the Internet does routing, when it really mostly does forwarding. Imagine yourself standing inside of a busy back-bone router. Packets arrive with a source and destination address which are not likely local. Your task is to forward the packet on the proper interface. You do not add anything to the front of the packet to "route it", you just forward it to the next best place where the process happens again, and again, etc. It is very unfortunate that routers from behind-the-times companies are not designed to handle the large tables required to do forwarding. Since you have suggested that more /24s be allowed, you might want to consider a different type of software design to handle a worst case scenario. Let's imagine that ALL possible /24s needed to be supported. Let's also imagine that your forwarder (not router) could have up to 256 interfaces. With 24 bits and a 1 byte wide table, you would need 16,777,216 bytes to describe all possible /24s and the interface a packet should be forwarded on. That is not a lot of memory in this day and age. Also, once the table was filled in, the lookup would be very fast. A packet would arrive, you would look at the most significant 24 bits of the destination, pull out the 8 bit interface id and place it on the queue for that interface to be forwarded as soon as the link was available. Unfortunately, router companies do not build devices that forward very well, and they also do not build devices that do routing very well. Before we look at routing, we should observe that most of the current routing companies organize their route tables based on assumptions about a sparse number of entries. Because of that the algorithms can not be fast and the processing required to make adjustments to their data structures can be much greater than simple changes to our hypothetical, brut-force, table above. Because, of poor engineering and design assumptions from the 80's when memory and processing was not cheap, Internet network operators are stuck living in a world where the rules are biased toward the ancient legacy systems. Those rules not only help to keep people in the mind-set where they buy the legacy equipment, the rules also make it such that large, legacy-laden, network providers are favored over the small, more leading-edge ISPs. In my opinion, this will all soon come to a point where people realize that the Internet needs more routing and less emphasis on forwarding. Sure, people could try to get companies to build systems that forward better, but that may not have as large a payoff as the move to routing. Routing will likely work best at the edges of the net and not in the core. Routing will require more intelligence than forwarding. Routing will be more involved in QoS and optimizing the balance in ATM circuit switching and IP forwarding. When the two are combined with processing power and more sophisticated protocols, true routing can occur. In the meantime, you are stuck with forwarding and with machines that do not support the notion that a huge number of /24s can be advertised. Some day, this may not be the case. Jim Fleming Unir Corporation - http://www.unir.com End-2-End: VPC(Java)---C+@---<IPv8>---C+@---(Java)VPC http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://www.ddj.com/index/author/idx10133.htm