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. Regards, David On Thu, Sep 6, 2012 at 9:38 AM, Will Orton <will@loopfree.net> 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