TE-18.2 QoS policer matching on next-hop-group

[dplore]

Note: This test is related to TE-18.1 and TE-18.3

[OpenConfigBot]

Pull Request Functional Test Report for #3383 / db7fba21033f3209db130cb9ef83e370354b0d58

No tests identified for validation.

Help

[coveralls]

Pull Request Test Coverage Report for Build 11171496245

Details

• 0 of 0 changed or added relevant lines in 0 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage remained the same at 55.268%

---

Totals
Change from base Build 11156251176:	0.0%
Covered Lines:	1983
Relevant Lines:	3588

---

💛 - Coveralls

[LimeHat]

Thanks Darren, (to continue the conversation from #3363) As an alternative to the proposed policer definition, I would suggest implementing something like /qos/policer-policies/ (similar to /qos/scheduler-policies), where the ingress policers can be defined.

And interface association can be defined via /qos/interfaces/interface[interface-id=*]/input/policer-policy

Note that there's already an existing classifier-to-interface association via /qos/interfaces/interface/input, so the newly proposed classifier association to a policy /qos/input-policies/input-policy/config/classifier creates ambiguity.

Additionally, w.r.t.

  # qos interface config
  #/qos/interfaces/interface/subinterface/input/config/policies:   # TODO:  new OC leaf-list (/qos/interfaces/interface/input/config/policies)

/qos/interfaces/interface component can be used to reference interfaces or subinterfaces depending on the interface-ref config, so there's no need for the additional subinterface context, it will be implied by the interface-ref (where subinterface is present). This is, for instance, how classifiers operate already in a number of implementations.

Unrelatedly, matching on next-hop-group is unusual, especially for the ingress policer. Most implementations that I know of operate based on packet/frame fields; and knowledge of the destination NHG requires the implementation to perform a FIB lookup first, before performing the policing action. I can't comment on feasibility, but I have some concerns.

[dplore]

@LimeHat

introduced new OC subtree (/qos/input-policies) The operational use case is to configure schedulers (policers) on input subinterfaces Today OC requires definition of queues for schedulers but in practice, input policing typically does not involve queues A new input-policies subtree is proposed here, relating classifiers and schedulers to each other. input-policies are then applied to an interface with a new OC leaf-list (qos/interfaces/interface/input/policies)

Is there an open PR for this already? (I wasn't able to find it)

I would argue that this may not be an optimal solution. Overloading the scheduler-policies, which are fundamentally responsible for queue management with additional, unrelated functionality (definition/instantiation of ingress policers on subinterfaces) is questionable.

There is no open PR for the proposed OC model in this README yet.

How should ingress policers be configured on a VOQ style device? The current QoS model does not directly describe how to implement ingress policers on a VOQ style device.

OC currently combines the notion of policer and queue servicing into one entity. This isn't an overload based on what is defined today in OC. (although maybe it should be changed?)

I think the only option for an input policer in the current OC model is to assume there is an input queue as well. In a device which only (abstractly) implements an output queue, does it make sense to go ahead and use the existing qos model and have two queues and consider the input queue doesn't really exist but can be configured with a scheduler that only supports policing?

Ingress policing only on input and queuing only on output is a very common scenario. It seems we should have a direct way to model it. This README currently proposes option "A", but there are some other ideas in the drawing below.

[dplore]

@LimeHat I like the /qos/policer-policies/ concept better, so I revised the proposed structure to use it. WDYT now?

Let's generate some rough consensus on the structure here. The NHG as a match criteria I think requires a lot more discussion in realtime due to a large number of factors as to whether this is suitable and feasible in hw and sw.

[vishnureddybadveli]

/qos/policer-policies/ concept is looking better Darren Loher.

[dplore]

I made a major revision of the scheduler configuration to align with the current, unmodified OC /qos model. Note that the input-queue is a dummy queue required to satisfy the required relationships in the OC model.

Here is what the relationships in the OC qos model look like. I plan to add this diagram and example configuration to the qos documentation, but thought I would share it here first as this test serves as a canoncial use case for ingress policing on a device without input queues.

I'd like to ask for feedback on these options

1. Using a dummy queue is simple enough and aligns with the current node relationships. (which if so, meets use cases with and without input queuing and scheduling).

2. adding yet another relationship in the schema to define a new input-type enum of "FORWARDING_GROUP". This has a benefit of avoiding a "dummy queue", but slightly increases the model complexity by adding another relationship to an already complex schema.

3. Some other suggestion?

[dplore]

@LimeHat @nandanarista @earies @rgwilton for comment on the QoS model for ingress policing example here.

[dplore]

@vishnureddybadveli this is ready to merge, noting that there are a few TODO items. You can take up updates for future revisions.

[dplore]

Thanks for all the comments. CLosing this and tracking development here on the dp-2.2 branch. When it's closer to ready to be merged, a new PR will be created.