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

Reply via email to