Muni Fiber and Politics

Corey Touchet corey.touchet at
Fri Aug 1 15:04:16 UTC 2014

Not really, the law can say  must provide standards compliant access for
interconnections with a agreed upon base set of features it must support.
Any provider that wants something extra can negotiate the reasonable costs
of implementation.

On 8/1/14, 8:44 AM, "Owen DeLong" <owen at> wrote:

>On Aug 1, 2014, at 12:08 AM, Mark Tinka <mark.tinka at> wrote:
>> On Friday, August 01, 2014 08:54:07 AM mcfbbqroast . wrote:
>>> This would be my humble suggestion:
>>> - lines provider runs fibre pair from each home to co. By
>>> default the lines provider installs a simple consumer
>>> terminal, with gigabit Ethernet outputs and POTS.
>The problem with this is it allows the lines provider to dictate
>the technology to be used by all higher-layer service providers.
>IMHO, this is undesirable, because it blocks innovation and
>service differentiation on this basis.
>Ideally, the lines provider is simply a lines provider and provides
>a number of dark fiber pairs between the serving wire center (what
>you called a CO) and each premise served by the SWC.
>Termination at the customer end should be a box in which a customer
>terminal can be installed and the fibers should all be terminated on
>some standard form of patch panel (ST or LC probably preferred,
>but others may be acceptable).
>It would then be up to the service provider(s) to provide the terminals
>and decide between customer self-install and truck-rolls for service
>>> - lines provider provides a reasonably oversubscribed
>>> service to soft hand over to ISPs (think 96 Gbps lines
>>> to 2 10gbps ports). Perhaps upgrading so such a ratio
>>> never becomes congested could be a requirement?
>Putting the lines provider into this part of the equation preserves
>many of the problems with the existing model.
>>> -  lines provider also rents individual lines to ISPs
>>> which they can use directly. Rent should be lower than
>>> soft handover.
>Now you¹ve got competition operating at a disadvantage to the
>incumbent lines provider, preserving this aspect of the problems
>with the current system. IMHO, this should be the only service
>the lines provider is allowed to sell. In that way, the lines provider
>is not in competition with its wholesale customers.
>If you want examples of how well the model you propose tends to
>work, look no further than the incredible problematic nature of MCI¹s
>attempt to offer local phone service over Pacific Bell/SBC/AT&T
>>> This way ISPs can easily offer services. POTS over VoIP
>>> can be setup on installation of the terminal (so
>>> handover to the ISP is seamless). Finally business and
>>> residential services can also be provided over the fibre
>>> directly (this will be attractive to ISPs with many
>>> ports, to reduce costs, and premium/business ISPs to add
>>> control).
>This is also true of dark fiber pairs, with the added advantage
>that the service providers can differentiate themselves on
>chosen technology, can offer innovative services and can
>leverage existing infrastructure to deploy newer technologies as
>they develop.
>>> - ideally the lines provider would aid in providing cheap
>>> backhaul from the co (while still allowing 3rd party
>>> users to bring fibre in).
>I don¹t think this is so ideal. Again, it creates an opportunity for
>the lines provider to leverage their infrastructure in a way that it
>can become a barrier to competition. This is, IMHO, the opposite
>of good.
>> Wholesale mode. Doable.
>> Works best if the lines provider is not a service provider;
>> or regulation in your market ensures a service provider who
>> is also a lines provider is mandated to unbundle at
>> reasonable cost.
>Even when mandated to unbundle at a reasonable cost, often
>other games are played (trouble ticket for service billed by
>lines provider resolved in a day, trouble ticket for service on
>unbundled element resolved in 14 days, etc.).
>IMHO, experience has taught us that the lines provider (or as I
>prefer to call them, the Layer 1 infrastructure provider) must be
>prohibited from playing at the higher layers.

More information about the NANOG mailing list