Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add status flags for transceiver host lanes and media channels #1197

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Add status flags for transceiver host lanes and media channels #1197

wants to merge 1 commit into from

Conversation

nkitchen-arista
Copy link

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

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

@nkitchen-arista nkitchen-arista requested a review from a team as a code owner October 10, 2024 01:06
@dplore
Copy link
Member

dplore commented Oct 15, 2024

/gcbrun

@dplore
Copy link
Member

dplore commented Oct 15, 2024

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

@OpenConfigBot
Copy link

OpenConfigBot commented Oct 15, 2024 •
edited
Loading

No major YANG version changes in commit a7e1b7c

@dplore
Copy link
Member

dplore commented Oct 15, 2024

/gcbrun

@ejbrever
Copy link
Contributor

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
Copy link
Author

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
Copy link
Author

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
Copy link
Contributor

ejbrever commented Oct 20, 2024 •
edited
Loading

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
ejbrever approved these changes Oct 21, 2024
View reviewed changes
Copy link
Contributor

@ejbrever ejbrever left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@nkitchen-arista
Copy link
Author

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

That's right.

@dplore
Copy link
Member

dplore commented Oct 22, 2024

Setting last call for Nov 5, 2024

@dplore
Copy link
Member

dplore commented Oct 22, 2024

/gcbrun

@nkitchen-arista
Add status flags for transceiver host lanes and media channels
597ef60 
These flags are 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 analogous list /components/component/transceiver/host-lanes/lane to
hold them.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@ejbrever ejbrever ejbrever approved these changes

At least 1 approving review is required to merge this pull request.

Assignees

@ejbrever ejbrever

Labels
non-breaking
Projects
OC Operator Review
Status: last-call
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@nkitchen-arista @dplore @OpenConfigBot @ejbrever