Re: constant FEC errors juniper mpc10e 400g

[Saku Ytti <saku () ytti fi>]

On Sat, 20 Apr 2024 at 10:00, Mark Tinka <mark@tinka.africa> 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 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 RFI signal would be between you and transponder, so
these connections can be, and regularly are, provided without proper
end-to-end hardware liveliness, and even if they were delivered and
tested to have proper end-to-end HW liveliness, that may change during
operation, so line faults may or may not be propagated to both ends as
RFI assertion, and even if they are, how delayed they are, they may
suffer delay to allow for optical protection to engage, which may be
undesirable, as it eats into your convergence budget.

Of course the higher we go in the abstraction, the less likely you are
to get things like HW livelines detection, like I don't really see
anyone asking for this in their pseudowire services, even though it's
something that actually can be delivered. In Junos it's a single
config stanza in interface, to assert RFI to client port, if
pseudowire goes down in the operator network.

-- 
  ++ytti