On 4/22/24 09:47, Vasilenko Eduard via NANOG wrote:
Assume that some carrier has 10k FBB subscribers in a particular municipality
(without any hope of considerably increasing this number).
2Mbps is the current average per household in the busy hour, pretty uniform
worldwide.
You could
ers are connected
to the Internet at a fast rate.
Ed/
-Original Message-
From: NANOG On Behalf Of
Tarko Tikan
Sent: Saturday, April 20, 2024 19:19
To: nanog@nanog.org
Subject: Re: constant FEC errors juniper mpc10e 400g
hey,
> That said, I don't expect any subsea cables getting
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,
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
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
-PHY anymore.
-- Original message --
From: Mark Tinka
To: Dave Cohen
Cc: nanog@nanog.org
Subject: Re: constant FEC errors juniper mpc10e 400g
Date: Sat, 20 Apr 2024 17:50:04 +0200
WAN-PHY did not extend to 40G or 100G, which can explain one of the reasons it
lost favour. For 10G
On 4/20/24 18:19, Tarko Tikan wrote:
10G wavelengths for new builds died about 10 years ago when coherent
100G became available, submarine or not. Putting 10G into same system
is not really feasible at all.
I was referring to 10G services (client-side), not 10G wavelengths (line
side).
hey,
That said, I don't expect any subsea cables getting built in the next 3
years and later will have 10G as a product on the SLTE itself... it
wouldn't be worth the spectrum.
10G wavelengths for new builds died about 10 years ago when coherent
100G became available, submarine or not.
On 4/20/24 14:41, Dave Cohen wrote:
LAN PHY dominates in the US too. Requests for WAN PHY were almost exclusively
for terrestrial backhaul extending off of legacy subsea systems that still
commonly had TDM-framed services. It’s been a couple of years since I’ve been
in optical transport
LAN PHY dominates in the US too. Requests for WAN PHY were almost exclusively
for terrestrial backhaul extending off of legacy subsea systems that still
commonly had TDM-framed services. It’s been a couple of years since I’ve been
in optical transport directly but these requests were
On 4/20/24 13:39, Saku Ytti wrote:
Oh I don't think OTN or WAN-PHY have any large deployment future, the
cheapest option is 'good enough'...
And what we find with EU providers is that Ethernet and OTN services are
priced similarly. It's a software toggle on a transponder, but even
then,
On 4/20/24 13:39, Saku Ytti wrote:
Oh I don't think OTN or WAN-PHY have any large deployment future, the
cheapest option is 'good enough' and whatever value you could extract
from OTN or WAN-PHY, will be difficult to capitalise, people usually
don't even capitalise the capabilities they
On Sat, 20 Apr 2024 at 14:35, Mark Tinka wrote:
> Even when our market seeks OTN from European backhaul providers to extend
> submarine access into Europe and Asia-Pac, it is often for structured
> capacity grooming, and not for OAM benefit.
>
> It would be interesting to learn whether other
On 4/20/24 13:25, Saku Ytti wrote:
In most cases, modern optical long haul has a transponder, which
terminates your FEC, because clients offer gray, and you like
something a bit less depressing, like 1570.42nm.
This is not just FEC terminating, but also to a degree autonego
terminating, like
On Sat, 20 Apr 2024 at 10:00, Mark Tinka wrote:
> This would only matter on ultra long haul optical spans where the signal
> would need to be regenerated, where - among many other values - FEC would
> need to be decoded, corrected and re-applied.
In most cases, modern optical long haul has a
On 4/19/24 10:08, Saku Ytti wrote:
Of course there are limits to this, as FEC is hop-by-hop, so in
long-haul you'll know about circuit quality to the transponder, not
end-to-end. Unlike in wan-phy, OTN where you know both.
Technically optical transport could induce FEC errors, if there are
On 4/19/24 10:08, Saku Ytti wrote:
Of course there are limits to this, as FEC is hop-by-hop, so in
long-haul you'll know about circuit quality to the transponder, not
end-to-end. Unlike in wan-phy, OTN where you know both.
Technically optical transport could induce FEC errors, if there are
On Fri, 19 Apr 2024 at 10:55, Mark Tinka wrote:>
FEC is amazing.
> At higher data rates (100G and 400G) for long and ultra long haul optical
> networks, SD-FEC (Soft Decision FEC) carries a higher overhead penalty
> compared to HD-FEC (Hard Decision FEC), but the net OSNR gain more than
>
On 4/19/24 08:01, Saku Ytti wrote:
The frames in FEC are idle frames between actual ethernet frames. So
you recall right, without FEC, you won't see this idle traffic.
It's very very good, because now you actually know before putting the
circuit in production, if the circuit works or not.
On Thu, 18 Apr 2024 at 21:49, Aaron Gould wrote:
> Thanks. What "all the ethernet control frame juju" might you be referring
> to? I don't recall Ethernet, in and of itself, just sending stuff back and
> forth. Does anyone know if this FEC stuff I see concurring is actually
> contained in
I'm being sloppy with my verbiage, it's just been a long time since
I thought about this in detail, sorry.
The MAC layer hands bits to the Media Independent Interface, which connects
the MAC to the PHY. The PHY converts the digital 1/0 into the form required
by the media transmission type; the
On 4/18/24 11:45, Aaron Gould wrote:
Thanks. What "all the ethernet control frame juju" might you be
referring to? I don't recall Ethernet, in and of itself, just sending
stuff back and forth. Does anyone know if this FEC stuff I see
concurring is actually contained in Ethernet Frames?
> What "all the ethernet control frame juju" might you be referring
> to? I don't recall Ethernet, in and of itself, just sending stuff back and
> forth.
I did not read the 100G Ethernet specs, but as far as I remember
FastEthernet (e.g. 100BASE-FX) uses 4B/5B coding on the line, borrowed
from
Thanks. What "all the ethernet control frame juju" might you be
referring to? I don't recall Ethernet, in and of itself, just sending
stuff back and forth. Does anyone know if this FEC stuff I see
concurring is actually contained in Ethernet Frames? If so, please send
a link to show the
FEC is occurring at the PHY , below the PCS.
Even if you're not sending any traffic, all the ethernet control frame juju
is still going back and forth, which FEC may have to correct.
I *think* (but not 100% sure) that for anything that by spec requires FEC,
there is a default RS-FEC type that
Not to belabor this, but so interesting... I need a FEC-for-Dummies or
FEC-for-IP/Ethernet-Engineers...
Shown below, my 400g interface with NO config at all... Interface has no
traffic at all, no packets at all BUT, lots of FEC hits. Interesting this
FEC-thing. I'd love to have a fiber
On 4/18/24 15:45, Tom Beecher wrote:
Just for extra clarity off those KB, probably has nothing to do with
vendor interop as implied in at least one of those.
Yes, correct.
Mark.
>
> We've seen the same between Juniper and Arista boxes in the same rack
> running at 100G, despite cleaning fibres, swapping optics, moving ports,
> moving line cards, e.t.c. TAC said it's a non-issue, and to be expected,
> and shared the same KB's.
>
>
Just for extra clarity off those KB,
Standard deviation is now your friend. Learned to alert on outside of SD
FEC and CRCs. Although the second should already be alerting.
On Thu, Apr 18, 2024 at 8:15 AM Mark Tinka wrote:
> On 4/17/24 23: 24, Aaron Gould wrote: > Well JTAC just said that it seems
> ok, and that 400g is going to
In my reading the 400GBASE-R Physical Coding Sublayer (PCS) always
includes the FEC. This is defined in clause 119 of IEEE Std 802.3-2022,
and most easily seen in "Figure 119–2—Functional block diagram" if you
don't want to get buried in the prose. Nothing there seems to imply that
the FEC is
On 4/17/24 23:24, Aaron Gould wrote:
Well JTAC just said that it seems ok, and that 400g is going to show
4x more than 100g "This is due to having to synchronize much more to
support higher data."
We've seen the same between Juniper and Arista boxes in the same rack
running at 100G,
Corrected FEC errors are pretty normal for 400G FR4
On Wednesday, April 17th, 2024 at 3:36 PM, Aaron Gould wrote:
> We recently added MPC10E-15C-MRATE cards to our MX960's to upgrade our core
> to 400g. During initial testing of the 400g interface (400GBASE-FR4), I see
> constant FEC errors.
FEC on 400G is required and expected. As long as it is “corrected”, you have
nothing to worry about. We had the same realisation recenty when upgrading to
400G.
-Schylar
From: NANOG on behalf of Aaron
Gould
Date: Wednesday, April 17, 2024 at 2:38 PM
To: nanog@nanog.org
Subject: constant
Well JTAC just said that it seems ok, and that 400g is going to show 4x
more than 100g "This is due to having to synchronize much more to
support higher data."
-Aaron
On 4/17/2024 4:04 PM, Aaron Gould wrote:
Interesting, thanks all, the JTAC rep got back to me and also pretty
much said
Interesting, thanks all, the JTAC rep got back to me and also pretty
much said it's not an issue and is expected... also, JTAC rep sited 2
KB's, shown here, both using 100g as an example... question please,
should I understand that this is also true about 400g, even though his
KB's speak about
At some point, an error rate would exceed the ability of forward error
correction (FEC) overhead to compensate, resulting in CRC errors. You're
not seeing those so all is technically well.
It's not so much how many packets come in with errors that causes a
problem, but what percentage of each
Notes I found that I took from smart optical people :
"PAM4 runs at much lower SNRs than NRZ, because you're trying to read 4
distinct voltage levels instead of 2.Even the cleanest system will have
some of that, so the only way to make it usable is to have FEC in place."
On Wed, Apr 17, 2024
Hi.
Looks like normal behavior:
https://supportportal.juniper.net/s/article/PTX-FEC-corrected-errors-increasing-on-link-between-QSFP-100GBASE-SR4-740-058734-and-QSFP-100G-SR4-T2-740-061405?language=en_US
"An incrementing FEC Corrected Errors counter is normal for a link that
is running FEC.
Thanks Joe and Schylar, that's reassuring. Tom, yes, I believe fec is
required for 400g as you see fec119 listed in that output... and i
understand you can't (or perhaps shouldn't) change it.
-Aaron
On 4/17/2024 2:43 PM, Joe Antkowiak wrote:
Corrected FEC errors are pretty normal for 400G
fec cliff? is there a level of fec erros that i should be worried about
then? not sure what you mean.
-Aaron
On 4/17/2024 2:46 PM, Matt Erculiani wrote:
I'm no TAC engineer, but the purpose of FEC is to take and correct
errors when the port is going so fast that errors are
simply
Isn't FEC required by the 400G spec?
On Wed, Apr 17, 2024 at 3:45 PM Aaron Gould wrote:
> i did. Usually my NANOG and J-NSP email list gets me a quicker solution
> than JTAC.
>
> -Aaron
> On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
>
> Open a JTAC case,
> That looks like a work for them
>
I'm no TAC engineer, but the purpose of FEC is to take and correct errors
when the port is going so fast that errors are simply inevitable. Working
as Intended.
Easier (read: cheaper) to build in some error correction than make the bits
wiggle more reliably.
No idea if that rate of increment is
i did. Usually my NANOG and J-NSP email list gets me a quicker solution
than JTAC.
-Aaron
On 4/17/2024 2:37 PM, Dominik Dobrowolski wrote:
Open a JTAC case,
That looks like a work for them
Kind Regards,
Dominik
W dniu śr., 17.04.2024 o 21:36 Aaron Gould napisał(a):
We recently added
Open a JTAC case,
That looks like a work for them
Kind Regards,
Dominik
W dniu śr., 17.04.2024 o 21:36 Aaron Gould napisał(a):
> We recently added MPC10E-15C-MRATE cards to our MX960's to upgrade our core
> to 400g. During initial testing of the 400g interface (400GBASE-FR4), I see
>
44 matches
Mail list logo
