openconfig/public

Add media-channel expected-power to openconfig-channel-monitor

Closed this issue · 6 comments

Currently under the openconfig channel-monitor model, there is a leaf for measured power:

https://github.com/openconfig/public/blame/815341544e58548526e7f9bec4e0ed2d615b69ac/release/models/optical-transport/openconfig-channel-monitor.yang#L163

Power is reported as integrated power between lower-frequency and upper-frequency.
This allows system vendors to implement optical channel monitors which report per-media-channel optical powers, based on configured media-channel frequency ranges.

To supplement this, it would be helpful to add an additional leaf, "expected-power", which reports the optical power expected for a media-channel at the same system measurement point.
This would enable operators to easily identify discrepancies between measured and expected optical powers within the same OpenConfig model (channel-monitor).

A proposed implementation would look like:

leaf expected-power {
type decimal64 {
fraction-digits 2;
}
units dBm;
description
"Expected optical power over the specified spectrum";
}
}

In this proposal, both "power" and "expected-power" are "state" data (i.e. "expected-power" is not configured under the channel-monitor model).

System vendors can easily calculate expected powers based on wavelength-router port-spectrum-power-profiles, for example, defined at WSS input and output ports and optical amplifier line out ports.

Can you comment on the reason that expected-power should be configured on the device? My initial reaction is the expected power would be stored offline, in an NMS system which was measuring the actual values, doing the comparison and so on. Another question might be, is this value expected to used as an alarm threshold?

@dplore the intent here is to provide a leaf under /channel-monitor.../ where the system can report both "power" and "expected-power" at the same measurement point.
I slightly updated the original comment to clarify that the intention is to add "state" data, not configuration.

The general use case is something like:

  1. Operators configure a wavelength-router port-spectrum-power-profile (PSPP), e.g. at a WSS input port. A set of media-channels is also configured on the same port.
  2. System vendors already internally calculate the expected power per media-channel based on the defined PSPP (this is needed for optical channel control).
  3. System vendors already stream "power" for individual media-channels, under /channel-monitor.../power/.
  4. This proposal would allow system vendors to add "expected-power" under the same telemetry path.
  5. Operators then have a direct comparison of "power" and "expected-power" without having to do the calculation in the operators own SDN controller.

So this should simplify the use case where operators want both expected and measured power at a system measurement point (which is useful for troubleshooting).

Regarding alarming, systems generally raise alarms against discrepancies between "power" and internally calculated (outside OpenConfig) "expected-power" - however today that "expected-power" would be stored in the system vendors native model only and not available directly in OpenConfig.

@ejbrever any comments for us?

This seems like a good idea to me.

@kcroussore since thresholding was raised, this might be interesting to incorporate as well. Should we also add something like "max-power-deviation" which would allow us control when the device raises a corresponding alarm. I don't know if that is configurable at all today, but please let me know your thoughts.

Makes sense, an editorial comment: expectations can vary based on circumstances, so I would name it "target-power" to express that this is the power targeted at this point by network design.

@ggrammel and @ejbrever thank you for comments, I have changed this from "expected-power" to "target-power" and created a pull request.