Re: Muni Fiber and Politics

[Owen DeLong <owen () delong com>]

On Aug 4, 2014, at 10:27 AM, William Herrin <bill () herrin us> wrote:

> On Mon, Aug 4, 2014 at 12:35 PM, Owen DeLong <owen () delong com> wrote:
> > > > I can never see a case where letting them play at Layer 3 or above helps.
> > >
> > > Layers 2 and 3 are fuzzy these days. I think that's a bad place to draw a line.
> > >
> > > Rather draw the line between providing a local interconnect versus
> > > providing services and out-system communications.
> >
> > I think the best line to draw is between passive facilities and active components.
>
> Hi Owen,
>
> You've convinced me. However, I think it's still worth talking about
> where you draw the second line -- if the infrastructure provider
> implements a network with active components and some kind of digital
> data passing protocol, what should the scope of that capability be
> limited to?

I would think that is only acceptable if they are REQUIRED to provide bare-bones
passive L1 services wherever possible. (with the possible exception of amplifiers
which you deleted from my previous message).

> > > With a multi-service provider network there are, IMO, major advantages
> > > to implementing it with private-IP IPv4 instead of a layer 2 solution.
> > > No complicated vlans, PPoE or gpon channels. Just normal IP routing
> > > and normal access control filters available in even the cheap
> > > equipment. Then run your various virtual wire technologies (e.g. VPNs)
> > > over the IP network. Everybody is a peer on the network, so the
> > > infrastructure provider doesn't need to know anything about
> > > customer-service provider relationships and doesn't need to implement
> > > any special configurations in their network to serve them.
> >
> > In an already-sunk equipment cost environment, this might be a
> > necessary tradeoff. In a greenfield deployment, there's no reason
> > whatsoever not to use IPv6 GUA in place of RFC-1918 with the
> > added advantage that you are not limited to ~17 million managed
> > entries per management domain.
>
> Cost and availability of tools, equipment and personnel still strongly
> favors IPv4. Presumably that will eventually change, but it won't
> change for the equipment you can purchase today. The only point of
> providing lit service is to suppress the initial consumer-level cost,
> so let's not suggest choices that increase it.

IPv6 capable tools do not cost more than IPv4 capable tools these days,
so cost does not favor IPv4. As to availability, to some minor extent, but
that is a matter of demand. If we make IPv6 a requirement in such
circumstances, I guarantee you that availability for IPv6 capable tools
will improve rapidly.

I don’t believe that greenfield lit consumer service will reduce cost anyway.

Further, putting anything in the network today that is not IPv6 capable does
actually increase costs. Maybe not this week or even this year, but almost
certainly in less than 3-5 years at this point. At current growth rates, IPv6
will service more end users than IPv4 by the end of 2016.

> If the local infrastructure provider has a million customers in a
> single domain, it is too large to have implemented itself
> cost-effectively (they'll be using the super-expensive high-capacity
> low-production-run core equipment) and is straying into that
> undesirable territory where the infrastructure provider becomes a
> general service provider.

A management domain may span multiple service delivery domains.

It may be that a provider which consists of many small service delivery
domains wants to manage them as a single domain rather than running
some sort of split-brained set of management domains.

Owen