openconfig
Expand ACL model by rate-limits (a.k.a. policers) and counters.
Change Scope
This change introduces 2 new actions to ACL
- named counter for ACL entry
- named rate-limit for ACL entry
This change also introduces "scope" attribute for above, that controlls aggregation level of counting/rate-limiting. This has direct impact on number of counter, rate-limit instances that need to be instantiated in datapalane.
The reate-limits are refined in dedicated branch under /acl and are reusable across acl-sets and their entries
module: openconfig-acl
+--rw acl
+--rw rate-limits
+--rw rate-limit* [name]
+--rw name -> ../config/name
+--rw config
| +--rw name? string
| +--rw type? identityref
| +--rw cir? uint64
| +--rw cbs? uint32
| +--rw pir? uint64
| +--rw pbs? uint32
| +--rw conform-action
| | +--rw forwarding-action identityref
| | +--rw log-action? identityref
| | +--rw counter
| | +--rw enabled? boolean
| | +--rw scope?
| +--rw exceed-action
| | +--rw forwarding-action identityref
| | +--rw log-action? identityref
| | +--rw counter
| | +--rw enabled? boolean
| | +--rw scope?
| +--rw violate-action
| +--rw forwarding-action? identityref
| +--rw log-action? identityref
| +--rw counter
| +--rw enabled? boolean
| +--rw scope?
+--rw state
+--rw name? string
+--rw type? identityref
+--rw cir? uint64
+--rw cbs? uint32
+--rw pir? uint64
+--rw pbs? uint32
+--rw conform-action
| +--rw forwarding-action identityref
| +--rw log-action? identityref
| +--rw counter
| +--rw enabled? boolean
| +--rw scope?
+--rw exceed-action
| +--rw forwarding-action identityref
| +--rw log-action? identityref
| +--rw counter
| +--rw enabled? boolean
| +--rw scope?
+--rw violate-action
+--rw forwarding-action? identityref
+--rw log-action? identityref
+--rw counter
+--rw enabled? boolean
+--rw scope?
The named rate-limit and counters are ACL entries actions
module: openconfig-acl
+--rw acl
+--rw acl-sets
+--rw acl-set* [name type]
+--rw acl-entries
+--rw acl-entry* [sequence-id]
+--rw actions
+--rw config
| +--rw forwarding-action identityref
| +--rw rate-limit
| | +--rw name -> ../../../../../../../rate-limits/rate-limit/config/name
| | +--rw scope? identityref
| +--rw log-action? identityref
| +--rw log-action? identityref
| +--rw counter
| +--rw enabled? boolean
| +--rw scope?
+--ro state
+--ro forwarding-action identityref
+--ro rate-limit
| +--ro name -> ../../../../../../../rate-limits/rate-limit/config/name
| +--ro scope? identityref
+--ro log-action? identityref
+--ro log-action? identityref
+--ro counter
+--ro enabled? boolean
+--ro scope?
Atatachment of acl-set to interface (or control-plane-traffic) produces respective state
module: openconfig-acl
+--rw acl
+--rw interfaces
+--rw interface* [id]
+--rw ingress-acl-sets
+--rw ingress-acl-set* [set-name type]
+--ro acl-entries
+--ro acl-entry* [sequence-id]
+--ro state
+--ro sequence-id? -> /acl/acl-sets/acl-set[oc-acl:name=current()/../../../../set-name][oc-acl:type=current()/../../../../type]/oc-acl:acl-entries/acl-entry/sequence-id
+--ro forwarding-action? identityref
+--ro rate-limit-name? string <<
+--ro rate-limit-scope? identityref <<
+--ro matched-packets? oc-yang:counter64
+--ro matched-octets? oc-yang:counter64
+--ro oc-sys-copp:matched-scope? identityref <<
+--ro conformed-packets? oc-yang:counter64 <<
+--ro conformed-octets? oc-yang:counter64 <<
+--ro exceeding-packets? oc-yang:counter64 <<
+--ro exceeding-octets? oc-yang:counter64 <<
+--ro violating-packets? oc-yang:counter64 <<
+--ro violating-octets? oc-yang:counter64 <<
module: openconfig-system
+--rw system
+--rw oc-sys-copp:control-plane-traffic
+--rw oc-sys-copp:ingress
+--rw oc-sys-copp:acl
+--rw oc-sys-copp:acl-set* [set-name type]
+--ro oc-sys-copp:acl-entries
+--ro oc-sys-copp:acl-entry* [sequence-id]
+--ro oc-sys-copp:sequence-id -> ../state/sequence-id
+--ro oc-sys-copp:state
+--ro oc-sys-copp:sequence-id? -> /oc-acl:acl/acl-sets/acl-set[oc-acl:name=current()/../../../../set-name][oc-acl:type=current()/../../../../type]/oc-acl:acl-entries/acl-entry/sequence-id
+--ro oc-sys-copp:forwarding-action? identityref
+--ro oc-sys-copp:rate-limit-name? string
+--ro oc-sys-copp:rate-limit-scope? identityref
+--ro oc-sys-copp:matched-packets? oc-yang:counter64
+--ro oc-sys-copp:matched-octets? oc-yang:counter64
+--ro oc-sys-copp:matched-scope? identityref
+--ro oc-sys-copp:conformed-packets? oc-yang:counter64
+--ro oc-sys-copp:conformed-octets? oc-yang:counter64
+--ro oc-sys-copp:exceeding-packets? oc-yang:counter64
+--ro oc-sys-copp:exceeding-octets? oc-yang:counter64
+--ro oc-sys-copp:violating-packets? oc-yang:counter64
+--ro oc-sys-copp:violating-octets? oc-yang:counter64
Finally "scope" is enums that alows to control is given instance of rate-limit (token-buckets) is shared among multiple acl-entries of same acl-set instance, shared among entries of multiple acl-set instances but at same attachment point (e.g. interface direction), etc
Platform Implementations
- JUNIPER JUNOS: Firewall-Filters Configuring Policers to Control Traffic Rates
- Cisco IOS-XR : policy-map policy rate in ingress service-policy
No major YANG version changes in commit 8df21aeee09243747d34d35dc0ff185ebb3f4bb6
I have also added COPP VRF awarness
module: openconfig-system
+--rw system
+--rw oc-sys-copp:control-plane-traffic
+--rw oc-sys-copp:ingress
+--rw oc-sys-copp:network-instances
+--rw oc-sys-copp:network-instance* [name]
+--rw oc-sys-copp:name string
+--rw oc-sys-copp:config
| +--rw oc-sys-copp:name? string
+--rw oc-sys-copp:state
| +--rw oc-sys-copp:name? string
+--rw oc-sys-copp:acl
+--rw oc-sys-copp:acl-set* [set-name type]
+--rw oc-sys-copp:set-name -> ../config/set-name
+--rw oc-sys-copp:type -> ../config/type
+--rw oc-sys-copp:config
| +--rw oc-sys-copp:set-name? -> /oc-acl:acl/acl-sets/acl-set/config/name
| +--rw oc-sys-copp:type? -> /oc-acl:acl/acl-sets/acl-set[oc-acl:name=current()/../set-name]/config/type
+--ro oc-sys-copp:state
| +--ro oc-sys-copp:set-name? -> /oc-acl:acl/acl-sets/acl-set/config/name
| +--ro oc-sys-copp:type? -> /oc-acl:acl/acl-sets/acl-set[oc-acl:name=current()/../set-name]/config/type
+--ro oc-sys-copp:acl-entries
+--ro oc-sys-copp:acl-entry* [sequence-id]
+--ro oc-sys-copp:sequence-id -> ../state/sequence-id
+--ro oc-sys-copp:state
+--ro oc-sys-copp:sequence-id? -> /oc-acl:acl/acl-sets/acl-set[oc-acl:name=current()/../../../../set-name][oc-acl:type=current()/../../../../type]/oc-acl:acl-entries/acl-entry/sequence-id
+--ro oc-sys-copp:forwarding-action? identityref
+--ro oc-sys-copp:rate-limit-name? string
+--ro oc-sys-copp:rate-limit-scope? identityref
+--ro oc-sys-copp:matched-packets? oc-yang:counter64
+--ro oc-sys-copp:matched-octets? oc-yang:counter64
+--ro oc-sys-copp:matched-scope? identityref
+--ro oc-sys-copp:conformed-packets? oc-yang:counter64
+--ro oc-sys-copp:conformed-octets? oc-yang:counter64
+--ro oc-sys-copp:exceeding-packets? oc-yang:counter64
+--ro oc-sys-copp:exceeding-octets? oc-yang:counter64
+--ro oc-sys-copp:violating-packets? oc-yang:counter64
+--ro oc-sys-copp:violating-octets? oc-yang:counter64
I have concerns with this change -- can you explain why this isn't using the QoS model, and/or why it is applicable to all ACLs across the system?
I have concerns with this change -- can you explain why this isn't using the QoS model, and/or why it is applicable to all ACLs across the system?
- rate limit is not that exotic action, applicable in many places of system. Specificly on ingress interfaces, when limiting certain traffic is quite common need. So fare interfaces and control-plane-traffic are ONLY places when ACL could be attached. (Note rate-limits we have defined in
/qosare attributes of schedulers, hence apply only if you have queue. Many system has only output queues.) - Classifies in /qos are missing multiple matching options, that are crutial (TCP flags, ICMP codes, etc)
- Classifies in /qos support only one action - assign traffic-group. And we need count, rate-limit, discard, reject, log etc.
Sure we can extend /qos classifiers. E.g. making acl-set one of matching criteria and adding missing actions.
Or we can extend /acl as in this proposal. OR we can define new object "/traffic-policy" that has structure similar to /qos classifier but is "attachment point agnostic" - attachable to interfaces, control-plane, forwarding-table, qos/interface ...
@robshakir - WDYT ?
Hi @rszarecki,
We have the below of queries regarding your proposed model, can you please clarify?
- The proposed model does not define way to configure single rate three colour rate limiter RFC 2697 (SrTCM), right now only RL_1R2C, RL_2R3C are defined in the current proposed model. May I know what is plan to support RFC 2697 SrTCM Policer?
- What is plan to support colour aware and colour bind? Right now this is not supported in proposed model
- What’s the use case of “accept” under violate-action ?
- What’s the use case of “accept” under exceed-action?
- RFC 2697/2698 defines packet marking, but the proposed model doesn’t define a way to configure loss-priority, forwarding-class action for rate limiter. May I know what is plan to support it?
Thank and regards Rajat Rastogi
