Re: Muni fiber: L1 or L2?

[Owen DeLong <owen () delong com>]

On Feb 5, 2013, at 9:37 AM, Scott Helms <khelms () zcorum com> wrote:

> On Tue, Feb 5, 2013 at 11:30 AM, Jay Ashworth <jra () baylink com> wrote:
>
> > ----- Original Message -----
> > > From: "Scott Helms" <khelms () zcorum com>
> >
> > > > Yes it does... It locks you into whatever is supported on the ring.
> > >
> > > I don't know how I can explain this more plainly, I can (more accurately
> > > have) taken a fiber build that was created as a ring & spoke SONET system
> > > and with the same fiber plant overlaid that with GigE and ATM (further
> > back
> > > in time) to backhaul for PON, DSL, VOIP, and direct Active Ethernet.
> >
> > "Overlaid"?  Could you clarify that?
>
> Sure, ring, hub & spoke, home run, star these are all descriptions of the
> physical architecture and many layer 2 technologies will happily use them
> all including Ethernet.  To use a specific example an existing SONET ring
> (OC-3 to be precise) had be in service with an ILEC for more than a decade.
> This physical topology was a common one with a physical ring of fiber (32
> strands, yes this was built back in the day) connected to Add/Drop
> Multiplexers (Fujitsu IIRC) along the ring as needed to deliver 25,000 or
> shorter copper loops either directly from the same cabinet that ADM was in
> or from a subtended Digital Loop Carrier off of a spur (collapsed ring) of
> the ring.  Now, SONET connections work off a pair of fibers, one for
> transmit and one for receive.  To run Ethernet (initially 100mbps but now
> 10G) we simply lit 2 of the remaining 30 strands to overlay an Ethernet
> ring on top of the SONET ring.  We then placed switches in the same remote
> cabinets we had the ADMs and DLCs and started trenching the fiber drops.

However, for any given ring, you are locked into a single technology and
you have to put active electronics out in the field.

You can't, given a ring architecture, provide dark fiber leases.

I realize it is your argument that one doesn't need to do so, there's no market
for it, etc. However, I don't agree with you.

> > Owen's assertion (and mine) is that a loop architecture *requires* active
> > equipment, suited to the phy layer protocol, at each node.  And while those
> > loop fibers are running SONET, they can't be running anything else at the
> > same time.
>
> You're confounding the physical layer topology with the layer 2 protocol.
> You can't run SONET and Ethernet on the same physical fiber at the same
> time (unless you use WDM but that's confusing the discussion) but you'd
> never build a ring of fiber with only two strands.

Sure, but, you're ring only works with things that do L2 aggregation in the
field with active electronics in the field. This means that for any L2 technology
a particular subscriber wants to use, you need to either already have that L2
technology deployed on a ring, or, you need to deploy another ring to support
that technology.

> > > > Lower the price per instance and you very likely find new demands.
> > >
> > > The vast majority of business don't WANT that kind of connectivity.
> >
> > The vast majority of businesses don't want it at the price they have to
> > pay for it now -- or more to the point, the consultants who do their IT
> > don't.
> >
> > You have no real way, I should think, to extrapolate whether that will
> > continue as prices drop, especially if sharply.
>
> The vast majority of businesses don't know and don't care about HOW their
> connectivity is delivered and wouldn't know the difference between Layer 1
> and Layer 2 if it punched them in the face.  Almost all businesses want
> INTERNET connectivity at the highest quality & speed at the lowest cost and
> that's it.  There are a small percentage, mainly larger businesses, that do
> have special requirements, but those special requirements very seldom
> include a L1 anything.

VPNs are popular today (whether MPLS, IPSEC, or otherwise) because
L1 connections are expensive and VPNS are (relatively) cheap.

If dark fiber can be provided for $30/month per termination (we've already
agreed that the cost is $20 or less), that changes the equation quite a bit.
If, as a business, I can provide corporate connectivity and internet access
to my employees for $30/month/employee without having to use a VPN,
but just 802.1q trunking and providing them a router (or switch) that has
different ports for Corporate and Personal LANs in their house, that
changes the equation quite a bit.

Admittedly, this only works for the employees that live within range, but
it's an example of the kinds of services that nobody even imagines today
because we can't get good L1 services cheap yet.

> > > > You're assuming the current business model of incumbent-provider owned
> > > > fiber. In a case where you have service providers not allowed to own
> > fiber
> > > > and a fiber provider not allowed to provide services, the incentives
> > all
> > > > work towards cooperation and the conflicts of interest between them are
> > > > eliminated. I understand what you're saying about field technicians and
> > > > their motivations, but, again those are based largely on the current
> > > > business models and compensation schemes. In the proposed arena,
> > there's no
> > > > reason management at the service provider and management at the fiber
> > > > provider cannot work together to address these issues. Further, the
> > > > technician that blames the fiber plant for everything rather than
> > > > cooperating to resolve said issues together will inherently have his
> > > > installations take longer than the ones that cooperate, so he is
> > actually
> > > > already automatically incentivized in the correct direction.
> >
> > This is my goal.
> Its an admirable goal, but you're never going to have CCIEs (probably not
> even CCNAs) doing installs.  Installation is, has been, and will in all
> likelihood continue to be done by people with limited skill sets.  You
> building your own fiber plant and making it easier for ISPs to connect
> isn't going to change that.

Sure, but elsewhere you've pointed out that the last 20 yards are where most
of the problems occur… Guess what… The last 20 yards should be the service
provider, not the L1 in this case. If you're worried that the tech will blame problems
in the last 20 yards on the prem. loop, that's a matter of teaching them where
to plug in the box for testing the L1 loop.

MMR-------[B-Box]------[Customer Patch]------[IW Termination]

1.      Plug into IW Termination
                If it works, great, you're done. If not:

2.      Plug into Customer Patch.
                If it works, problem is isolated to the IW side of things, not the
                muni's responsibility.

                If it doesn't, contact the muni and schedule a joint visit to
                troubleshoot. Muni will provide an OTDR. Any modulation-specific
                diagnostic gear to be provided by the service provider.

I'm willing to bet that I could teach this to the average installer in a matter
of minutes.

The important factors at play here are:

        1.      The muni needs to be responsive and cooperative with the
                installers in addressing such issues.

        2.      The installers need to be willing to work cooperatively with
                the muni's technicians. Throwing tickets over the wall in a
                fire and forget scenario cannot be allowed (on either side).

        3.      The muni should have a contractual provision which allows
                them to charge back the ISP if they make a joint site visit
                and the problem is shown to be on the IW side of the
                equation.

In such a climate, the installers have an easy way to determine whether
the problem is actually on the muni side of the equation or not and an
incentive to get that call right.

The muni needs to have a high standard of customer service and
responsiveness to the service providers (their customers), but they
also have a strong incentive to do so since that is what will attract
providers to using their system.

The service providers are incentivized to properly train their installers
and require them to work well with the muni because that will provide
a better customer experience for their customers and reduce their
chargebacks from the muni.

IOW, the important thing is to align the economic incentives with the
desired outcomes.

> > Your assertion seems to be that it will be necessary to have "abnormal"
> > installers in the field in order for them not to dump problem tickets
> > off to the muni and fail to help meaningfully in fixing them.
> >
> > First, I think this unlikely since, in most cases, we'll have 3pr available
> > at each address.  If we think there's a problem with the pair, we can
> > "cut to clear" *temporarily*, and if the second pair is ok, then the sub
> > is back online while we test the first pair and clear the problem.
> >
> > (GTE's failure, for all that I give them shit about CtC is that they never
> > *worked* the dead pairs; as long as you do, it's not a problem.)
>
> That's great, and I'm glad to hear you've worked out that part of the drop
> but most of the problems occur from the drop into the house or office.  The
> last 20 yards are the most problematic and most changed.  This is where the
> installer matters most and why even good plant has bad installs.

Which is a really great argument for making that last 20 yards the responsibility
of the higher level provider.

Owen