Custom ACL Based Metering #1889
Conversation
Describes the Custom ACL Based Metering (CABM) feature design in SONiC.
|
/azp run |
|
|
No pipelines are associated with this pull request. |
|
/azp run |
|
No pipelines are associated with this pull request. |
|
Community review recording https://zoom.us/rec/share/29B51B0VyrGy4h27zWOcrKVfzRgto8ONES9h5QPRFjek-d2iFMRthW5mabfAG6TW.PN8n9aVAa1gO4D5u |
|
|
||
| #### **Configuration Flow** | ||
|
|
||
|  |
There was a problem hiding this comment.
If we are validating the ACL action policer capability based on information from STATE_DB, please use it in the diagram.
There was a problem hiding this comment.
The ACL-Orch saves the information in both STATE_DB and local DB. So in my case, I can just check the local DB.
| ##### ACL Table Type Table | ||
| When a new ACL table is created, SAI needs to receive a list of supported actions which the rules belonging to this table are allowed to use. | ||
| To support the new policer action, the custom table types table schema will be extended with a policer action attribute - **"POLICER_ACTION"** for the actions attribute field. | ||
|
|
There was a problem hiding this comment.
Please highlight the changes done on top of the existing tables for this feature.
| ... | ||
| + /* prevent deletion of policer that referenced by ACL rule. | ||
| + Note that new policer won't be referenced by any ACL rules initially */ | ||
| + must "not(../acl:sonic-acl/acl:ACL_RULE/acl:ACL_RULE_LIST[acl:policer_action=current()/name])" { |
There was a problem hiding this comment.
This may not be required, please double check.
There was a problem hiding this comment.
Sure, thanks. I'll update the HLD accordingly.
|
/azp run |
|
No pipelines are associated with this pull request. |
|
@venkatmahalingam @bingwang-ms Can you please review? |
| config acl add table [OPTIONS] <table_name> <table_type> | ||
|
|
||
| # Config new ACL rules --> new optional field 'policer_name' | ||
| config acl update full [OPTIONS] [--policer_name <policer_name>] <FILE_NAME> |
There was a problem hiding this comment.
Why not consider placing POLICER_ACTION in the JSON file for configuration as well?
|
|
||
| # Config new ACL rules --> new optional field 'policer_name' | ||
| config acl update full [OPTIONS] [--policer_name <policer_name>] <FILE_NAME> | ||
| config acl update incremental [OPTIONS] [--policer_name <policer_name>] <FILE_NAME> |
There was a problem hiding this comment.
If the --policer option is used, can you explain how acl-loader converts the actions configured in the JSON, and whether it is consistent with the mirror processing logic?
|
|
||
| --- | ||
| ### Requirements | ||
| #### Functional Requirements |
There was a problem hiding this comment.
Perhaps you could explain how to handle updates to the policer—whether it's better to create a new policer and re-associate it with the ACL rule, or to directly update the attributes of the existing policer?
Describes the Custom ACL Based Metering (CABM) feature design in SONiC.
[AclOrch] Custom ACL Based Metering[sonic-buildimage] Custom ACL Based Metering[sonic-utilities] Custom ACL Based Metering