On Mon, 5 Jan 2009, Yakov Rekhter wrote: > Few points: > > - Even if one assumes that the growth rate of prefixes exceeds the > rate of speed improvements in the underlying DRAM that is used to > implement control plane, and that, in turn, would result in cost > increases, let's not forget that deploying new routing architecture > may have its own cost, thus resulting in cost increases. Moreover, > these increases may be higher relative to what would result from > the growth rate of prefixes exceeding the rate of speed improvements > in the underlying DRAM. > > These increases, just like the increases you mentioned above, > would need to be absorbed by the system, and "most likely to > propagate to the end users, with a net detriment to the growth > of the network". Moreover, these increases would need to be > absorbed by the system in the short/medium term, well before we > will reach "the promise" of the cost reduction in the *long > term*. Would the industry be willing to buy into the *promise* of > "a paradise" in the *long* term at the price of fairly certain > cost increases in the *short/medium* term ? > > All of the above means that a "promise" of cost reduction in the > *long* term may not be sufficient - the new routing architecture > needs to deliver in the *short/medium* term sufficient *tangible* > benefits to justify its *short/medium* term cost. > > - One may argue that the real problem is not in the cost increases, > but in the way how these increases are absorbed by the system. > Namely, the real problem is that those who do not benefit > are still required to pay for covering the cost imposed by those > who do benefit. That applies both to the current system, as well > as to any proposal for a new routing architecture.
It is important to point out that in the past the need driving the cost increases to scale routers was either amount of bandwidth (as customers wish to pass more traffic) or port density (as more customers desire to connect). Both of these come with an increase in revenue for the provider, and as such (if the economics make sense) can justify the cost of the upgrades. We are currently faced with a need to upgrade routers due to the amount of the routing state (and potentially the frequency with which it changes). These conditions are not necessarily a reflection of increasing customer demand or increasing revue, and in fact a large portion of this problem is originated by non-customers. <insert Geoff Huston discussion on problems with a routing economy> Charging non-customers per prefix to install routes in my routing table seems like it would take the Network Neutrality problem to a whole new level. Finally WRT absorbing the cost within the system you will need to consider: 1. What pricing model do vendors use for routers such that a moderately low end CPE that can carry multiple views of full routes (think cisco 7200 for customer with a single T1 to each of four different providers) remains affordable to small enterprises without making the cost of high end routes grow logarithmically as they keep up with table growth. 2. Routers have to be of sufficient scale to provide large ISPs enough time to complete certification, schedule maint windows and fully deploy all of the new devices, and hopefully depreciate the assets for 5 years before starting the cycle all over. 3. Are the added costs a one time event? Can this even be roll into a normal refresh cycle? Or are the added costs recurring, such as upgrading chassis every 3 years at a cost increase? 4. who should bear the burden of the extra cost? Should ISPs that must be default free carry a larger burden? What about end-sites that are not required to be default free, but desire it for better TE? Should ISPs that are default free with many routers carry a larger burden than DFZ ISPs with few routers? Consider that the number of routers in an ISPs network does not necessarily impact the number of routes they source into the DFZ. Should this cost just be passed along to an ISP's customers? If so then you reward the ISP that flood the DFZ with routes, and penalize the ISPs who aggregate well. __Jason _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
