TE-18.1 gRIBI MPLS in UDP encap and decap with input-policy
Test specification for gRIBI encap/decap with an input-policy which classifies and polices incoming packets using a one-rate, two color marker.
Several TODO items exist to acknowledge planned additions to the test.
Highlights
- 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-policiessubtree is proposed here, relating classifiers and schedulers to each other. -
input-policiesare then applied to an interface with a new OC leaf-list (qos/interfaces/interface/input/policies)
Pull Request Functional Test Report for #3363 / 38d525ef15e0a699da8fa1aa82f7916ec53d6e70
No tests identified for validation.
Pull Request Test Coverage Report for Build 10949735360
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.314%
| Totals | |
|---|---|
| Change from base Build 10933491950: | 0.0% |
| Covered Lines: | 1983 |
| Relevant Lines: | 3585 |
💛 - Coveralls
Overall changes are good.
@vishnureddybadveli see latest change at: https://github.com/openconfig/featureprofiles/pull/3363/files/bfcadd11237ec96f7872a88a8062346d74f55695..b5f414856305b5b065d61067598b3d80baa678e8
-
I added a commit correcting the UDP to GRE encap for the default encap gRIBI entry. Also I couldn't remember if we wanted gnmi config or gRIBI for the default encap (I know we want gnmi config for the default decap and that's in the README now).
-
refactored the minimum ttl rule into a gRIBI parameter for the mpls-in-udp encap. This seemed more than using a qos configuration or adding in some policy-forwarding config.
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.
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.
Thanks for the feedback, there is no open PR for the proposed OC model in this README. Note the policer configuration has been moved to https://github.com/openconfig/featureprofiles/pull/3383. Let's discuss there.
decap rules to use policy-forwarding changes looks good.
Changes looks good to me.
@trlongth @jaingaurav12 all comments addressed. Please review, thanks.
I made a couple of corrections and I think this is looking good now with no planned changes.