Are people still building SONET networks from scratch?

david peahi davidpeahi at
Mon Sep 10 17:55:26 UTC 2012

In my neck of the woods, critical locations often exist "in the middle of
nowhere", resulting in underserved facilities, where best effort networks
such as metro Ethernet cannot be trusted to remain available 24x7x365. Many
times, during prime business hours,  I will see a telco metro Ethernet
spanning tree convergence which results in my traffic re-routing for 20-30
seconds over my private backup network path, then switching back to the
metro Ethernet path after the telco technicians have finished their
maintenance. Several times when I have called in a trouble ticket, the
telco tech has asked "what is the big deal, it was only a 20 second
outage?". In the Enterprise environment, a planned spanning tree
convergence in the middle of business hours is one of the quickest ways for
a network engineer to be relieved of their duties, but apparently the bar
is considerably lower in the telco environment.
Not only that, but the telco SLAs associated with metro Ethernet are
totally bogus, with a best round trip SLA of 20 milliseconds, ranging up to
50 milliseconds for "bronze" service. For short distances of 100 miles or
less (rule of thumb is that light travels over fiber at 0.80 x speed of
light, or 1000 miles in 10 milliseconds), an SLA of 20-50 milliseconds
 amounts to fraud,  just another way for the telcos to scam the consumer.
The tone of many of the entries on this thread where the user is depicted
as being unreasonable, underscores the need for a coordinated national
broadband policy in the USA, based upon the Australian model in which the
government is building out fiber to every residence and business, no matter
where they are located.


On Thu, Sep 6, 2012 at 9:38 AM, Will Orton <will at> wrote:

> We've run into an issue with a customer that has been confounding us for a
> few
> months as we try to design what they need.
> The customer has a location in the relative middle of nowhere that they are
> trying to build a protected OC3 to. Ultimately, their traffic on it will be
> packet data (IP/ethernet, not channelized/voice). But they seem to be
> absolutely 100% set on the idea that they build with Cisco ONS boxes and
> that
> they run and control the D1-D12 bytes in order to manage protection
> switching
> on the OC3 (and have their DCC channel for management).
> Since this is the middle of nowhere, we are having to piece it together
> from a
> few runs of dark fiber here and there and lit services from about 3 other
> providers to get from the desired point A to the desired point B. The
> issues
> we seem to be hitting are:
> -We seem to be unable to find anyone who sells lit OC3 with D1-D12
> transparency for the client. Sometimes we can get D1-D3, but that's it.
> -lit OC3/12/48 is ridiculously expensive comapred to 1g ethernet waves or
> 10g
> waves (choice LAN/WAN ethernet or OC192)
> 10g waves are cheap enough that we have entertained the idea of buying
> them and
> putting OC-192/muxponders on the ends to provide the OC-3, but even then
> I'm
> having trouble finding boxes that will do D1-D12 transparency for client
> OC-3.
> Building the whole thing on dark fiber so that we could specify the exact
> equipment on every hop isn't going to happen, as the "protect" path is
> about
> 1000 miles and the geography is such that we don't really have a market
> for all
> the other wasted capacity there would be on that path.
> Having much more experience with ethernet/packet/MPLS setups, we are
> trying to
> get the client to admit that 1g/10g waves running ethernet with QoS would
> be as
> good as or better in terms of latency, jitter, and loss for their packet
> data.
> So far they will barely listen to the arguments. And then going the next
> leap
> and showing them that we could work towards <50ms protection switching with
> MPLS/BFD/etc packet-based protocols is another stretch.
> Am I missing something here that my customer isn't, or is it the other way
> around?
> -Will

More information about the NANOG mailing list