Add status flags for transceiver host lanes and media channels

[nkitchen-arista]

Change Scope

• This change adds leaf nodes for several status flags defined in the CMIS spec. Some of them are also defined in the earlier specs for management interfaces of SFP+ and QSFP+ modules.
• Some of the flags are specific to media channels. They are defined in
  the existing list /components/component/transceiver/physical-channels/channel.
• Other flags are specific to electrical host lanes. This change adds a new list /components/component/transceiver/host-lanes/lane to hold them, analogous to physical-channels/channel.
• This change is backwards compatible.

Tree View

(including the unchanged beginning of the channel list, for context)

--- oldtree.txt 2024-10-08 23:58:55.826051270 +0000
+++ newtree.txt 2024-10-08 23:54:19.131792033 +0000
@@ -79,7 +79,7 @@
        |     +--ro interval?   oc-types:stat-interval
        |     +--ro min-time?   oc-types:timeticks64
        |     +--ro max-time?   oc-types:timeticks64
        +--rw physical-channels
        |  +--rw channel* [index]
        |     +--rw index     -> ../config/index
        |     +--rw config
@@ -119,6 +119,9 @@
        |        |  +--ro interval?   oc-types:stat-interval
        |        |  +--ro min-time?   oc-types:timeticks64
        |        |  +--ro max-time?   oc-types:timeticks64
+       |        +--ro tx-failure?                   boolean
+       |        +--ro rx-los?                       boolean
+       |        +--ro rx-cdr-lol?                   boolean
        |        +--ro output-frequency?             oc-opt-types:frequency-type
        |        +--ro output-power
        |        |  +--ro instant?    decimal64
@@ -144,6 +147,15 @@
        |           +--ro interval?   oc-types:stat-interval
        |           +--ro min-time?   oc-types:timeticks64
        |           +--ro max-time?   oc-types:timeticks64
+       +--rw host-lanes
+       |  +--rw lane* [lane-number]
+       |     +--rw lane-number    -> ../config/lane-number
+       |     +--rw config
+       |     |  +--rw lane-number?   uint8
+       |     +--ro state
+       |        +--ro lane-number?   uint8
+       |        +--ro tx-los?        boolean
+       |        +--ro tx-cdr-lol?    boolean
        +--rw thresholds
           +--ro threshold* [severity]
              +--ro severity    -> ../state/severity

Platform Implementations

• Reference Arista EOS

switch#show transceiver status interface Ethernet34/1
Current System Time: Wed Oct  9 17:59:11 2024
                                Current State        Changes       Last Change
                                -------------        -------       -----------
Port 34
  Transceiver                   400GBASE-FR4               1       0:54:09 ago
[...]
Ethernet34/1
  Operational speed             400Gbps
  RX LOS
    Channel 1                   ok                         4       0:52:21 ago
    Channel 2                   ok                         4       0:52:21 ago
    Channel 3                   ok                         4       0:52:21 ago
    Channel 4                   ok                         4       0:52:21 ago
  TX fault
    Channel 1                   ok                         0       never
    Channel 2                   ok                         0       never
    Channel 3                   ok                         0       never
    Channel 4                   ok                         0       never
  RX CDR LOL
    Channel 1                   ok                         4       0:52:21 ago
    Channel 2                   ok                         4       0:52:21 ago
    Channel 3                   ok                         4       0:52:21 ago
    Channel 4                   ok                         4       0:52:21 ago
[...]
  TX LOS
    Host lane 1                 ok                         0       never
    Host lane 2                 ok                         0       never
    Host lane 3                 ok                         0       never
    Host lane 4                 ok                         0       never
    Host lane 5                 ok                         0       never
    Host lane 6                 ok                         0       never
    Host lane 7                 ok                         0       never
    Host lane 8                 ok                         0       never
  TX CDR LOL
    Host lane 1                 ok                         0       never
    Host lane 2                 ok                         0       never
    Host lane 3                 ok                         0       never
    Host lane 4                 ok                         0       never
    Host lane 5                 ok                         0       never
    Host lane 6                 ok                         0       never
    Host lane 7                 ok                         0       never
    Host lane 8                 ok                         0       never

[dplore]

/gcbrun

[dplore]

Hi @ejbrever , can you give this a review for us?

[OpenConfigBot]

No major YANG version changes in commit 98fc4a7

[dplore]

/gcbrun

[ejbrever]

It is good to see some of the failure modes start getting added directly within places in the model as we had intended long ago when we proposed the alarms model. So happy to see that.

I'm good with the three under the physical-channels.

I was hoping to discuss more on the new host-channelslist because I have some concern this conflicts with the terminal-device/logical-channels. The thinking was that electrical/digital things went to the logical-channels, whereas anything analog/physical is intended for the physical-channels. This feels like we are creating a new list that overlaps with logical channels. One option could be to use logical channels (which we definitely do for coherent optics, such as ZR).

Another option I was wondering about is if these actually do fit in physical-channel? tx-los for instance sounds more physical for example anyway?

[nkitchen-arista]

Another option I was wondering about is if these actually do fit in physical-channel? tx-los for instance sounds more physical for example anyway?

That's not how I read the CMIS spec [1]. In Table 8-77 that I referenced, it states that Tx LOS and Tx CDR LOL are indexed by host lane, not by media lane (channel), in contrast with the other flags. For some media types (such as 400GBASE-FR4 in my CLI output above), these won't map one-to-one, so we can't use the same list physical-channels for the host lanes and the media channels.

I suppose you could read this section of openconfig-platform-transceiver.yang:

A transceiver will always contain physical-channel(s), however
when a line side optical-channel is present (i.e. ZR+ optics)
the physical-channel will reference its optical-channel.

as meaning that an optical module should always use physical-channels for the host lanes and optical-channel for the media channels. But I think that implies that /components/component/transceiver/physical-channels/channel/state/input-power, output-power, and laser-bias-current would never be used, because non-optical modules would never have those DOM readings.

[1] http://www.qsfp-dd.com/wp-content/uploads/2021/05/CMIS5p0.pdf

[nkitchen-arista]

I was hoping to discuss more on the new host-channelslist because I have some concern this conflicts with the terminal-device/logical-channels. The thinking was that electrical/digital things went to the logical-channels, whereas anything analog/physical is intended for the physical-channels. This feels like we are creating a new list that overlaps with logical channels. One option could be to use logical channels (which we definitely do for coherent optics, such as ZR).

I'm having a hard time seeing the references to logical channels in https://github.com/openconfig/public/blob/master/release/models/optical-transport/openconfig-terminal-device.yang as matching up with host lanes. For example, I've never heard of "grooming" being applied to electrical host lanes. And some of the descriptions of LLDP-related nodes in that YANG module seem to refer to PDUs being sent on individual logical channels. But we wouldn't think of a packet as being sent on a single host lane out of 4 or 8, if the port was configured at maximum speed.

[ejbrever]

Ah, thanks for bearing with me and providing more detail. I think this makes sense to introduce a place for host lane telemetry. I suppose host lanes would always be read-only since there is nothing configurable on this side? I was initially thinking on the other side of the transceiver which is where the terminal-device model starts to come into play, but that's unrelated here.

[ejbrever]

LGTM

[nkitchen-arista]

I suppose host lanes would always be read-only since there is nothing configurable on this side?

That's right.

[dplore]

Setting last call for Nov 5, 2024

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

/gcbrun

[dplore]

Reviewed with oc operators on Nov 26,2024 with no objections. Given the host lanes and status flags are defined in CMIS specification, we deemed this as vendor neutral.