Add ingress policer to qos overview

[dplore]

Adding documentation on how to use the /qos model to create an ingress policer

[OpenConfigBot]

No major YANG version changes in commit 3f91434

[robshakir]

Given that we don't have a spec for YANG modelled data being serialised to YAML, can we write this as JSON please?

[dplore]

Converted to legal JSON, so the comments are gone. Do you want me to add them back in even though it cannot be validated? 😜

[dplore]

@robshakir ready for your re-review

[LimeHat]

I don't think this is the appropriate way to describe a canonical ingress policer.

While the scheduling typically supports rate-limiting mechanisms, in many implementations, there are separate policer entities (often implemented in HW) that are independent of schedulers; i.e., those are two different mechanisms.

The fake queuing/ingress scheduling approach feels more like a workaround for implementations where true ingress policers are not available (or they never implement "real" ingress scheduling and can perform this config translation into policing in native yang/cli model).
IMO it is fine if you want to describe that use case here, but stating that this is the (only) canonical way severely limits the range of covered scenarios and use cases.

In my view, the clearer approach is to introduce a new hierarchy to be used specifically to define standalone policers (e.g. /qos/policer-policies). This avoids any ambiguity w.r.t fake ingress queuing and allows for better extensibility.

[dplore]

@robshakir Ready for your next review