Muni network ownership and the Fourth

George Herbert george.herbert at
Wed Jan 30 04:36:11 UTC 2013

On Tue, Jan 29, 2013 at 8:10 PM, Leo Bicknell <bicknell at> wrote:
> In a message written on Tue, Jan 29, 2013 at 07:46:06PM -0800, Owen DeLong wrote:
>> Case 2, you move the CO Full problem from the CO to the adjacent
>> cable vaults. Even with fiber, a 10,000 strand bundle is not small.
>> It's also a lot more expensive to pull in 10,000 strands from a few
>> blocks away than it is to drop a router in the building with the MMR
>> and aggregate those cross-connects into a much smaller number
>> of fibers leaving the MMR building.
> [snip]
>> But what happens when you fill the cable vaults?
> It's really not an issue.  10,000 fibers will fit in a space not
> much larger than my arm.
> I have on my desk a 10+ year old cable sample of a Corning 864
> strand cable (36 ribbons of 24 fibers a ribbon).  It is barely
> larger around than my thumb.  Each one terminated into an almost-full
> rack of SC patch panels.
> A web page on the cable:
> My company at the time build a duct bank by building 6x4" conduit,
> installing 3x1.25" innerduct in each conduct, and pulling one of
> those cables in each innerduct.  That's a potential capacity of
> 15,525 fibers in a duct bank perhaps 14" wide by 8" tall.
> A "vault" as used for traditional telco or electrical (one big
> enough for a man to go down in) could hold millions of these fibers.
> They were never used, because they were way too big.  There's also
> plenty of experience in this area, telcos have been putting much
> larger copper cables into CO's for a long time.
> Were there demand, they could easily put more ribbons in a single
> armored sheeth.  The actual stack of fibers is about 1/2" wide and
> 3/8" thick for the 864 strands.  You could extrapolate a single
> 10,000 strand cable that would be smaller than the power cables
> going to a typical commercial transformer.
> The cost of fiber is terminating it.  Running 864 strands from one
> end of a colo to another inside, compared with running it a block
> down the street isn't significantly different; modulo any construction
> costs.  Obviously if it costs $1M to dig up the street that's bad,
> but for instance if there is already an empty duct down the street
> and it's just pulling cable, the delta is darn near zero.
> That's why I think rather than having the muni run colo (which may
> fill), they should just allow providers to drop in their own fiber
> cables, and run a fiber patch only room.  There could then be hundreds
> of private colo providers in a 1km radius of the fiber MMR, generating
> lots of competition for the space/power side of the equation.  If one
> fills up, someone will build another, and it need not be on the same
> square of land....

It's more than just terminating it; the bulk fiber is not free.  And
it's not the customer end where you see congestion; unless you
(expensively) splice out in the field at intermediate aggregation
points, for a say 10,000 customer "wire center" you have 10,000 x the
individual cable cross section area at the convergence point.  Which
you have to provision end-to-end unbroken as splicing is likely to
screw with your overall cost model in an atrocious way.  Unlike all
the other media.

Yes, you can buy some fiber that aggregates smaller bundles, but they
don't split nicely 100 ways in a manner you can realistically fan out
from one master bundle at the head end (unless there's a fiber type
out there I am not aware of, I don't do this part of the stuff all the

It's a pain in the ass to provision in a way that you can centralize a
L1 dark fiber service, because of splices.  If you're providing L2
then you don't splice, you just run to a pole or ground or vault box
and terminate there, and have a few 10G or 40G or 100G uplink fibers
from there to your interchange point "wire center".  If you're
providing L1 then that's an amazingly complex fiber pull / conduit /
delivered fiber quality / space management problem at the wire center.

-george william herbert
george.herbert at

More information about the NANOG mailing list