Re: constant FEC errors juniper mpc10e 400g
On 4/21/24 08:12, Saku Ytti wrote: Key difference being, WAN-PHY does not provide synchronous timing, so it's not SDH/SONET compatible for strict definition for it, but it does have the frame format. And the optical systems which could regenerate SONET/SDH framing, didn't care about timing, they just wanted to be able to parse and generate those frames, which they could, but they could not do it for ethernet frames. Correct. In those days, WAN-PHY was considered "SONET/SDH-Lite". I think it is pretty clear, the driver was to support long haul regeneration, so it was always going to be a stop-gap solution. Even though I know some networks, who specifically wanted WAN-PHY for its error reporting capabilities, I don't think this was majority driver, majority driver almost certainly was 'thats only thing we can put on this circuit'. SONET/SDH did have similar reach as OTN back then, just less bandwidth for the distance. It had FEC support for STM-16, STM-64 and STM-256. I really think the bigger driver was interface cost, because EoS had already been selling for 1GE alongside STM-16 for 2.5G. In those days, if you needed more than 1G but less than 10G, it was a toss-up between 2x 1G EoSDH vs. 1x STM-16. Often times, you took the 2x 1G EoSDH because 2x 1GE ports were cheaper than 1x STM-16 port, even though you ended up losing about 405Mbps of capacity in the process, which was a huge deal. The backbone providers did not like selling EoSDH services, because it was too much admin. for them (VC container management), and they ended up paying more for transponders on their side than their customers did for Ethernet ports on theirs :-). But by and large, the majority of networks in our market maintained SDH services long after coherent became commercially available. It was a perception thing, that SDH was more superior to Ethernet, even if that Ethernet was transported over a DWDM network. In the end, SDH port costs were too hard to ignore due to router vendors maintaining their mark-up on them despite dying demand, which then led to the migration from SDH to EoDWDM growing significantly from about 2016. Optical vendors also began de-prioritizing SDH transponder ports, which had a massive impact on the SLTE (submarine) side in making the decision to encourage customers away from SDH for wet services. Mark.
Re: constant FEC errors juniper mpc10e 400g
On Sun, 21 Apr 2024 at 09:05, Mark Tinka wrote: > Technically, what you are describing is EoS (Ethernet over SONET, Ethernet > over SDH), which is not the same as WAN-PHY (although the working groups that > developed these nearly confused each other in the process, ANSI/ITU for the > former vs. IEEE for the latter). > > WAN-PHY was developed to be operated across multiple vendors over different > media... SONET/SDH, DWDM, IP/MPLS/Ethernet devices and even dark fibre. The > goal of WAN-PHY was to deliver a low-cost Ethernet interface that was > SONET/SDH-compatible, as EoS interfaces were too costly for operators and > their customers. > > As we saw in real life, 10GE ports out-sold STM-64/OC-192 ports, as networks > replaced SONET/SDH backbones with DWDM and OTN. Key difference being, WAN-PHY does not provide synchronous timing, so it's not SDH/SONET compatible for strict definition for it, but it does have the frame format. And the optical systems which could regenerate SONET/SDH framing, didn't care about timing, they just wanted to be able to parse and generate those frames, which they could, but they could not do it for ethernet frames. I think it is pretty clear, the driver was to support long haul regeneration, so it was always going to be a stop-gap solution. Even though I know some networks, who specifically wanted WAN-PHY for its error reporting capabilities, I don't think this was majority driver, majority driver almost certainly was 'thats only thing we can put on this circuit'. -- ++ytti
Re: constant FEC errors juniper mpc10e 400g
On 4/20/24 21:36, b...@uu3.net wrote: Erm, WAN-PHY did not extend into 40G because there was not much of those STM-256 deployment? (or customers didnt wanted to pay for those). With SONET/SDH, as the traffic rate increased, so did the number of overhead bytes. With every iteration of the data rate, the overhead bytes quadrupled. This was one of the key reasons we did not see field deployment of STM-256/OC-768 and STM-1024/OC-3072. For example, if SONET/SDH had to transport a 100G service, it would require 160Gbps of bandwidth. That clearly wasn't going to work. At the time when STM-256/OC-768 was being developed, DWDM and OTN had come a long way. The granularity SONET/SDH required to stand up a service had become too small for the growing data rate (primarily VC-3, VC-4 and VC-12). If you look at OTN, the smallest container is 1.25Gbps (ODU0), which was attractive for networks looking to migrate from E1's, E3's, STM-1's, STM-4's and STM-16's - carried over VC-12, VC-4 and VC-3 SDH circuits - to 1GE, for example, rather than trying to keep their PDH/SDH infrastructure going. DWDM and OTN permitted a very small control overhead, so as data rates increased, there wasn't the same penalty you got with SONET/SDH. WAN-PHY was designed so people could encapsulate Ethernet frames right into STM-64. Once world moved out of SDH/SONET stuff, there was no more need for WAN-PHY anymore. Technically, what you are describing is EoS (Ethernet over SONET, Ethernet over SDH), which is not the same as WAN-PHY (although the working groups that developed these nearly confused each other in the process, ANSI/ITU for the former vs. IEEE for the latter). WAN-PHY was developed to be operated across multiple vendors over different media... SONET/SDH, DWDM, IP/MPLS/Ethernet devices and even dark fibre. The goal of WAN-PHY was to deliver a low-cost Ethernet interface that was SONET/SDH-compatible, as EoS interfaces were too costly for operators and their customers. As we saw in real life, 10GE ports out-sold STM-64/OC-192 ports, as networks replaced SONET/SDH backbones with DWDM and OTN. Mark.
