p1CalculateEthernetKpis behavior undefined for negative counter values before default value removal

[redchy]

Problem

When computing Ethernet KPIs, some input counters may be negative (commonly -1 meaning “default value”), e.g.:

"errored-frames-output": -1,
"dropped-frames-output": -1

Currently, the processing chain calculates Ethernet KPIs before default values are removed (default removal happens later : p1RemoveDefaultValues). This can produce artificial KPI values derived from default inputs, and the spec does not define what should happen in such cases.

Details

• If -1 means “not available”, then calculating KPI values from it is ambiguous:
  • Should the function compute frame-loss-output = -2 (mathematically correct but likely meaningless)?
  • Or should it treat negative inputs as invalid and return an error like:
    - frameLossOutput could not be provided
• Similar ambiguity applies to other KPIs:
  • transmit/receive traffic derived from total-bytes-*
  • frame-loss-input from ingress counters

Also, since these KPIs are “artificial”, they are not naturally covered by the default-value-removal (p1RemoveDefaultValues) logic (which typically deletes a single default value such as -1, not a computed range).

References

• spec/.../p1CalculateEthernetKpis/1.0.0/interface.yaml defines KPI computations such as:

frame-loss-output:
  description: >
    'Total frame loss on egress
    from [ {$input#/errored-frames-output} + {$input#/dropped-frames-output} ]'

…but does not mention how to handle invalid/negative inputs.

Solution proposal
In p1CalculateEthernetKpis/interface.yaml, update the KPI computation descriptions to exclude invalid inputs, e.g.:

• “Only compute KPI if inputs are valid non-negative integers; otherwise return input could not be provided.”

(Exact validity rule can be defined as: >= 0 for frame counters; and for bytes, either forbid negative strings or treat them as invalid.)

Additional note / follow-up

Please also check whether the same pattern exists in other KPI computations (e.g. p1CalculateUtilization), where derived KPIs may be computed from counters that can be -1 before default value removal.