openconfig
Add utilization leaves for memory blocks in pipeline-counters model
(M) release/models/platform/openconfig-pipeline-counters.yang -Add leaf for each memory attribute to indicate utilization
This proposal seeks to add three new leaves to the OpenConfig pipeline-counters model to represent ASIC memory utilization as relative values.
The primary motivation behind this proposal is that these leaves provide a more vendor and architecture agnostic measurement of memory utilization, and offload the often complex logic of deriving an accurate utilization of memory to the implementor (vendor). Lookup, nexthop, and ACL memories vary greatly across vendors and implementations. Each can be implemented on a variety (and combination) of memory types (e.g., TCAM, SRAM, various types of DRAM) and using a wide variety of search approaches and data structures. For instance, Juniper's express family of ASICs uses several different memories, search algos, and data structures just for ACL/filter programming which makes representing usage in entries or bytes difficult and ultimately low signal.
Several vendor implementations today yield relative values - EOS does so for both ACL and lookup memory (usage/util metrics): https://eos.arista.com/introduction-to-managing-eos-devices-platform-specific-monitoring-and-troubleshooting/
IOS-XR also vends relative utilization values per lookup table (page 126): https://www.ciscolive.com/c/dam/r/ciscolive/us/docs/2018/pdf/BRKARC-3000.pdf
Thanks for the contribution @aredmon8551. These are for convenience since it is trivial to derive from the existing memory and usage leaves, right? I would like to hear from the community if these are important and have solicited feedback from [email protected] and [email protected].
Ack, thanks @dplore - to be more blunt than my initial paragraph/readme: this is necessity, not convenience. The units of measurement and modeling for these memories does not map to complex implementations.
Ack, thanks @dplore - to be more blunt than my initial paragraph/readme: this is necessity, not convenience. The units of measurement and modeling for these memories does not map to complex implementations.
Apologies, I re-read your original description. So should the bytes and entries used/total leafs be removed and only relative / % utilizations be used?
@dplore I would recommend that, though my proposal here is to invite the least amount of change necessary to allow Juniper to support this model.
The current units of measurement do pose challenges for more complex ASIC architectures - I would recommend making this model less opinionated on what units to measure ASIC memories in and simply use relative units (percent).
Edit: grammar
@dplore - we are unfortunately blocked on implementing this state model until these changes are accepted. Can you let me know if this proposal is acceptable? Thanks!
Another proposal is pending that is similar but offers additional schema. @anuraagmittal @rolandphung
@dplore @rsgcp @xw-g @aredmon8551 -- it seems generally that these changes that remain in the PR (i.e., additions of percentage utilisation) are orthogonal to the wider questions. Can we move ahead with this change?
@aredmon8551 can Juniper support what is specified in #624 ? Will review with you as we would prefer to have one way to expose integrated circuit resource utilization.
Believe we can support #624 though I do see value in updating this model to be flexible enough to support a broader variety of network ASICs/future-proof things a bit.
to update this thread, some discussion as to exactly what the right split of data is ongoing -- such that we're stalled a little here. @dplore is leading that work.