On Jan 21, 2008 10:28 PM, Jon Lewis <[EMAIL PROTECTED]> wrote: > Is there really any point in trying to put a $ figure on each route?
Jon, Emphatically Yes! Right now we rely on ARIN and the RIRs to artificially suppress the growth of the prefix count and with it the availability of PI space. This is a Really Bad Thing on so many levels, but absent a viable market-based solution to the problem, authority-based rationing is really the only thing we can do. If we can determine the cost to announce a prefix then we could develop a market-based solution to the problem... One where instead of suppressing the prefix count and dealing with it as business overhead, we GET PAID for announcing and propagating prefixes. There are several market models that could work, but they all depend on having a reliable metric for the cost of announcing a prefix. So, if you think you'd like to get paid for announcing routes instead of continuing to give the service away for free then yes, there is a point to determining the cost of a prefix. On Jan 21, 2008 6:14 PM, David Barak <[EMAIL PROTECTED]> wrote: > Wouldn't a reasonable approach be to take the sum of a 6500/msfc2 and a 2851, > and assume that the routing computation could be offloaded? David, No, because the FIB can't be offloaded; it has to sit on the router's forwarding plane and it has to keep up. Between the low single-digit gbps and the low double-digit gbps, equipment which both keeps up and supports a large prefix count is significantly more expensive than equipment which keeps up but does not support a large prefix count. > The difficulty I have with this discussion is that the cost per prefix is > zero until you need to > change eigenstate, where there's a big cost, and then it goes back to zero > again. This is one of the harder aspects of operations cost analysis to wrap your head around. Not only isn't the operations cost attributable to a particular feature set bound to the associated manufacturing cost, it's different for different scenarios in which the equipment is used. To accurately assess the cost, you have to identify the boundary conditions that drive equipment selection. Let me construct two scenarios which illustrate this: Scenario A: You have 1U LAN switches serving 500 PCs at 100mbps and a few dozen servers at 1gbps. You want to upgrade to 1gbps to the PCs and 10gbps to the servers. You replace the 1U switches with 7600/sup720s. The cost driver in this scenario is the 10gbps server links. You can get 1U switches that stack and backbone at 10gbps but to hook up all the servers at 10gbps (to support the 1gbps workstations) you have to step up to the next class of equipment. This is the sole reason you need a 7600 instead of a few 1U gig-e switches. Therefore the 100% of difference in cost between a 7600 and a few 1U gig-e switches is attributable to the forwarding capacity required by the servers. In scenario A, the 7600's much larger prefix carrying capacity is not a cost driver. It plays no role in the decision to purchase a 7600 instead of 1U switches. As a result, the operations cost attributable to the 7600's larger prefix capacity is exactly zero. Scenario B: You have a metro ethernet POP moving 2 gbps of traffic with a couple 1U fiber switches. Use is gradually increasing; you project that 12 months out it will be 2.5gbps. For business reasons you want to extend the DFZ to this POP. You replace the 1U switches with a 7600/sup720-3bxl. The cost driver in this scenario is the DFZ extension, specifically the prefix count in the DFZ. At 2gbps, your existing equipment is not even close to tapped out, but it can't even think about carrying the DFZ's prefixes in its FIB. The sole reason you need a 7600 instead of a few 1U gig-e switches is the prefix count. Therefore the 100% of difference in cost between a 7600 and a few 1U gig-e switches is attributable to the prefix count required by the DFZ. Almost the exact same upgrade, but in one scenario the cost is attributable to the forwarding capacity and in the other its attributable to the prefix count. I think this is what's giving Patrick the most trouble as well. He wants equipment cost at an operations level to map to the component manufacturing cost as common sense says it should, but it doesn't work that way. Regards, Bill Herrin -- William D. Herrin [EMAIL PROTECTED] [EMAIL PROTECTED] 3005 Crane Dr. Web: <http://bill.herrin.us/> Falls Church, VA 22042-3004
