Update QoS AQM thresholds to support relative values

[aredmon8551]

• (M) openconfig-qos-mem-mgmt.yang

• (M) openconfig-qos-elements.yang

• (M) openconfig-qos-interfaces.yang

• (M) openconfig-qos.yang

  • Add 2 leaves representing percent values for RED min-threshold and max-threshold

This PR seeks to address two issues:

1. Since the first implementations of RED, there has been no consistent guidance on the units to use for queue-length (and therefore minth and maxth). Over the years implementations have used temporal, data, or percent values. This is to support percent values, which are 'unit-less' and a good approach for an abstraction.
2. Percent values carry the benefit of reducing configuration (i.e., syntactic sugar): a minth or maxth specified in bytes must be uniquely configured for every interface speed on a given platform. When specified in percent, a single set of thresholds can be applied to any interface speed.

Doing some analysis of vendor implementations:

1. Juniper supports relative (percent) thresholds (fill-level): https://www.juniper.net/documentation/us/en/software/junos/cos/topics/concept/red-drop-profile-overview-cos-config-guide.html

2. SR-Linux supports relative (percent) thresholds: https://documentation.nokia.com/srlinux/SR_Linux_HTML_R21-11/QoS_Guide/configuring_qos-ai9epsxdhf.html

3. EOS breaks out varying units depending on platforms - SoC platforms use 'segments', VoQ platforms look to use bytes: https://www.arista.com/en/um-eos/eos-quality-of-service

4. IOS-XR (ASR9K) looks to use bytes, packets, and temporal values: https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k-r6-2/qos/configuration/guide/b-qos-cg-asr9000-62x/b-qos-cg-asr9000-62x_chapter_0100.html

[OpenConfigBot]

Compatibility Report for commit 7cfe29f9b814d61a9d8113c7647d654da842aafc: ⛔ yanglint@SO 1.10.17

[robshakir]

Thanks for the proposal here -- and the documentation links. This looks reasonable to me.

@dplore @rolandphung @hellt @rgwilton - PTAL here :-)

[pranav-jnpr]

@dplore Could you please help review this?

[dplore]

I have added to the April 10th OC operators review

[sachendras]

@dplore you think we can close this soon?

[dplore]

Discussed at April 11th 2023 OC Operators meeting with comments that it's preferred to have one normalized configuration across devices. But it appears we have evidence that there are at least 3 ways to configure this (temporal, percent and bytes) exposed by devices today. All these reduce to bytes, but as noted there are tradeoffs in complexity of configuring bytes versus other methods.

In the end, there was no objection from OC Operators. As this has been open some time, I move to last call and merge on April 21, 2023.

(I will also fix the versioning issues)

[OpenConfigBot]

Major YANG version changes in commit 7cfe29f9b814d61a9d8113c7647d654da842aafc:

[dplore]

/gcbrun