Openconfig transceiver support fot FEC config and counters for breakout clients

[maljayac]

Hi Team,

Currently FEC config and counters for transceivers are under a single transceiver and not under each lane of the transceiver.

For pluggable form factors which support 100GE clients in each lane as breakout, for example, QDD-400G-DR4-S, we expect the FEC config as well as counters for each lane(physical-channel) representing each 100GE client separately.

Could we have fec config and counters for each physical-channels as well to accommodate this use case?

module: openconfig-platform-transceiver augment /oc-platform:components/oc-platform:component: +--rw transceiver +--rw config | +--rw fec-mode? identityref +--ro state | +--ro fec-mode? identityref | +--ro fec-status? identityref | +--ro fec-uncorrectable-blocks? yang:counter64 | +--ro fec-uncorrectable-words? yang:counter64 | +--ro fec-corrected-bytes? yang:counter64 | +--ro fec-corrected-bits? yang:counter64 +--rw physical-channels +--rw channel* [index] +--rw index -> ../config/index +--rw config +--ro state

[dplore]

@ejbrever could you comment?

[ejbrever]

As each physical channel should have an associated logical channel we could consider moving using some of the existing FEC leaves within the logical channels (although we might need to expand as well).

I vaguely remember having a discussion around the config of FEC in use cases like this a while ago. I think there was a thought that the config would have to be identical across each channel. Are there platforms offering the ability to set this at a more granular mode?

@jqjqlee @yawei-yin curious on your thoughts here. I think we might have had some similar discussions, but I cannot recall if we talked about breakout support.

[ejbrever]

Actually @jqjqlee would https://github.com/openconfig/models/pull/1038 help here?

[jqjqlee]

Actually @jqjqlee would openconfig/models#1038 help here?

I am afraid not. In PR#1038, we indeed added several FEC monitors which are defined in openconfig-terminal-device. These added FEC monitors are only targeting at use cases with coherent optics (e.g. 400ZR).

Based on my understanding, this issue @maljayac raised here is highly related to an existing problem in openconfig-platform-transceiver. It is a little bit complicated and we might need deeper discussions on this issue to move on this PR. It is suggested to involve Tad to the discussion.

For most of existing high-speed Ethernet standards, FEC is implemented in an end-to-end fashion. This means that there is no FECs terminated in gray optical transceivers (i.e. gray optical transceivers exclude PCS/FEC sublayers), and the FEC encoding/decoding is actually achieved in host ICs. In this regards, the FEC monitors are not supposed to appear in openconfig-platform-transceiver. I guess the initial idea of existing FEC monitors in openconfig-platform-transceiver is to take over the FEC monitors of host interfaces where the transceivers are plugged. If so, there would be conflicts and confusions for use cases where optical transceivers have PCS/FEC sublayers. For example, there are two FECs for 400GBASE-ZR in a segmented FEC architecture. As another example, IEEE802.3df is also considering to introduce segmented or concatenated FEC architecture for 200G/lane PMDs, where there will be two FECs in a single optical transceiver. Therefore, we need to address the above problem first prior to going to the details of breakout use cases.

One proposal is to add similar FEC monitors somewhere else (e.g. the interface module) to address the FEC monitoring issues in a end-to-end FEC architecture. The existing FEC monitors defined in openconfig-platform-transceiver is suggested to be confined to segmented or concatenated FEC architectures. Furthermore, we also need to add the other group of FEC monitors to accommodate two FECs in segmented FEC architecture. Anyway, there would be major changes to address this complicated issue. @ejbrever @yawei-yin @thofmeister

[github-actions[bot]]

This issue is stale because it has been open 180 days with no activity. If you wish to keep this issue active, please remove the stale label or add a comment, otherwise will be closed in 14 days.