Cost per prefix [was: request for help w/ ATT and terminology]

Joe Greco jgreco at ns.sol.net
Tue Jan 22 17:05:57 UTC 2008


> The problem with William's calculation is that he is claiming the  
> _only_ difference between X & Y is "prefix count".  (He said this,  
> more than once.)

The only meaningful difference between X & Y for the purposes of this
discussion _is_ prefix count.

> He is dead wrong.

No, he's quite right.

> I cannot think of a pair of boxes where one can support a full table  
> and one can't where the _only_ difference is prefix count.  

That's missing the point.

Let's say that I am buying a gig Ethernet switch.  I need 24 ports. 
I'm going to limit vendors to Dell, just to keep the options somewhat
limited, just as they are in the world of routing.

If I want an unmanaged switch, I can't get it.  I am forced to buy a
Dell 2724 "web-managed" switch for $279.  That's fine, for me, it's
still essentially an unmanaged switch, as I won't be willing/able to 
run Internet Explorer to manage it.

Now, if I want to include the ability to ssh into it and do interactive
stuff, such as scripting, then I'm looking at a different device.  I'm
forced to buy a Dell 5424 "managed" switch for $912.

The 5424 can do a *LOT* more than the 2724.  However, the single reason
*I* needed to pick the 5424 was due to ssh, and so even if the 5424 can
be managed via SNMP and do other neat stuff, those features mean nothing
to me, and the cost to me to obtain ssh as a feature is a bit over $600.
It's not $100 for ssh and $100 for SNMP and $100 each for each of four
other features.

> (I am  
> excluding things like "Box X with 128MB RAM and Box X with 1 GB  
> RAM".)

We know that will work for certain networks.  It is fair to establish 
that as the far low-end for calculating the incremental cost.

> Even the Sup2 & 3blx have far more differences than just  
> prefix count.  If you do not understand why, you clearly aren't  
> competent to post to this thread.

Of course they have far more differences than just prefix count.  That's
the way feature sets work.  I can't /buy/ a sup2-3bxl.  However, if I'm 
running a network today on a sup2, and I'm fine, EXCEPT that I am 
running out of prefixes, what do I do?

What DO I do?

If I choose to upgrade to the 3bxl, the _only_ meaningful difference 
between before and after is the prefix count.  The 3bxl may have some 
nifty other features, but I was getting along fine without them, and
even once I've upgraded, I'm just as likely to not be using them, so
the entire cost of the 3bxl upgrade can be attributed to the reason I
did the upgrade: support for the larger table size.

> For every network, there is equipment that will work, and equipment  
> that will not.  At the top end for very large networks, buying less  
> than a CRS1 / T640 is simply not an option.  And the amount of  
> engineering going into those boxes to deal with a 1M BGP entry table  
> is essentially _zero_.  Many networks buying those boxes have 100s of  
> 1000s of prefixes in their _IGP_, so the FIB / processor / RAM / etc.  
> all have to deal.

Yup.  Those may be balanced in some fashion by:

> Near the bottom end, for networks that could get away with a 3750 if  
> they only supported a full table (which I submit is a pretty small  
> fraction of the total boxes sold), they can still buy the 3750 and  
> default to a pair of cheap 2/3/4-port boxes with a gig of RAM and use  
> those for external connectivity.  The problem is perfectly solvable  
> without jumping to the 7600/3blx.

It is possible to cobble together a solution of some sort.  However,
that is equally likely to be inconvenient or exceedingly difficult,
based on the specifics of the network.  You seem to be aware of that:

> In between there are more variations than everyone here combined could  
> possibly imagine.  And the requirements are _NOT_ all about prefix  
> count.  Which means you have no basis for comparison.  If you try to  
> force a general comparison, you will be wrong.
> 
> So stop asking "what box would you compare?"  The answer is "whatever  
> I need!", not what YOU think is correct, since you are invariably  
> wrong unless you know everything about MY network.

Sure.  SO, for the purposes of this thread, the reasonable thing to do
is to try to do as direct a comparison as possible.  We want to know how
much extra the full table capability is.  While specific answers may vary
from provider to provider, it should be obvious that there's a cost of
some sort, and that for a typical bit of hardware, such as the 6500/7600,
it's the cost of the upgrade to 3bxl, plus whatever other upgrades you
might be forced to eat.

That's not to say that someone, somewhere, won't be replacing a 6500 with
a bunch of Linux PC's and a cheap switch, or some other cobbled-together
solution, and yes, then the answers change.  Patrick, this thread isn't
about the canonical way for a provider to upgrade, it's not even about a
real provider.  It's about the costs to a hypothetical provider.  The 
design and facts of your network are not particularly relevant.  We're
just looking for some numbers.

The reasonable thing to do, when you're just looking for some numbers, is
to come up with a reasonable way to generate those numbers, without giving
yourself an ulcer over the other possibilities of what may or may not be
on some specific network somewhere, or whether or not the other features
that come along with something like the upgrade to a sup720 should somehow 
be attributed to some other thing.

But getting back to this statement of yours:

> I cannot think of a pair of boxes where one can support a full table  
> and one can't where the _only_ difference is prefix count.  

I'll put a nail in this, AND cure some of your unhappiness, by noting the
following:

Per Froogle, which is public information that can be readily verified by
the random reader, it appears that a SUP720-3B can be had for ~$8K.  It 
appears that a SUP720-3BXL can be had for ~$29K.  IGNORING THE FACT that
the average network probably isn't merely upgrading from 3B to 3BXL, and
that line cards may need upgrades or daughtercards, that gives us a cost
of somewhere around $21K that can be attributed to JUST the growth in
table size.  (At least, I'm not /aware/ of any difference between the 3B 
and 3BXL other than table size.)

Will everyone decide to make that /particular/ jump in technology?  No.

Is it a fair answer to the question being asked?  It's a conservative
estimate, and so it is safe to use for the purposes of William's 
discussion.  It is a middle-of-the-road number.  There WILL be networks
that do not experience these costs, for various reasons.  There WILL be
networks where the costs are substantially higher, maybe because they've
got a hundred routers that all need to be upgraded.  There will even be
networks who have the 7600 platform and have already deployed the 3bxl.

The more general problem of "what does it cost to carry another route"
is somewhat like arguing about how many angels can dance on the head of
a pin.  Unlike the angels, there's an actual answer to the question, but
we're not able to accurately determine all the variables with precision.
That doesn't mean it's completely unreasonable to make a ballpark guess.

Remember the wisdom of Pnews:

"This program posts news to thousands of machines throughout the entire
civilized world.  Your message will cost the net hundreds if not thousands of
dollars to send everywhere.  Please be sure you know what you are doing."

This is hardly different, and we're trying to get a grasp on what it is 
we're doing.  Your input of useful numbers and estimates would be helpful
and interesting.  Your arguments about why it's all wrong, minus any better
suggestion of how to do it, are useless.  Sorry, that's just the way it is.

... JG
-- 
Joe Greco - sol.net Network Services - Milwaukee, WI - http://www.sol.net
"We call it the 'one bite at the apple' rule. Give me one chance [and] then I
won't contact you again." - Direct Marketing Ass'n position on e-mail spam(CNN)
With 24 million small businesses in the US alone, that's way too many apples.



More information about the NANOG mailing list