Skip to content

Commit

Permalink
Minor updates
Browse files Browse the repository at this point in the history
  • Loading branch information
prsunny authored Jul 6, 2023
1 parent 64cbb0a commit f1bf11d
Showing 1 changed file with 7 additions and 5 deletions.
12 changes: 7 additions & 5 deletions documentation/general/dash-sonic-hld.md
Original file line number Diff line number Diff line change
@@ -1,6 +1,6 @@
# SONiC-DASH HLD
## High Level Design Document
### Rev 1.4
### Rev 1.6

# Table of Contents

Expand Down Expand Up @@ -139,7 +139,7 @@ Metering is essential for billing the customers and below are the high-level req
- Mapping table based metering - E.g For specific destinations within the mapping table that must be billed separately
- Policy in the metering context refers to metering policy associated to Route tables. This is not related to ACL policy or any ACL packet counters.
- If packet flow hits multiple metering buckets, order of priority shall be **Policy->Route->Mapping**
- User shall be able to override the precedence between Routing and Mapping buckets by setting an _override_ flag. When policy is enabled for a route, it takes higher precedence than routing and mapping metering bucket.
- User shall be able to override the precedence between Routing/Policy and Mapping buckets by setting an _override_ flag. When policy is enabled for a route, it takes higher precedence than routing and mapping metering bucket unless _override_ flag is set wherein Mapping takes precedence
- Implementation shall aggregate the counters on an "_ENI+Metering Bucket_" combination for billing:
- All traffic from an ENI to a Peered VNET
- All traffic from an ENI to a Private Link destination
Expand Down Expand Up @@ -189,7 +189,7 @@ ACL is essential for NSGs and have different stages. In the current model, there
- No requirement to modify an existing rule except for the case above. For e.g change action of a rule from permit to deny or vice-versa
- ACL Tagging
- Mapping a prefix to a tag can reduce the repetition of prefixes across different ACL rules and optimize memory usage
- Tagging is implemented as a bitmap in Orchagent and SAI layers
- Tagging is implemented as a bitmap or list in Orchagent and SAI layers
- A prefix can belong to multiple tags
- Prefixes can be added or removed from a tag at any time
- SAI implementation shall return a capability for the bitmap size. A '0' return value shall be treated as no-tag support.
Expand All @@ -204,7 +204,7 @@ ACL is essential for NSGs and have different stages. In the current model, there
- If the tag field is empty, ACL rule must match ANY tag or NO tag.
- The bitmap size depends on the SAI implementation capability. It is fixed during initialization based on the capability value returned by SAI implementation. This same bitmap size shall be later used for ACL rules and prefix-tag mapping. Orchagent shall implement the logic to chose the tags with largest number of prefixes, based on the capability value. Say 8 biggest tags in the above example. Rest of the tags shall be expanded to include prefixes in the ACL rules.
- Deleting ACL group is permitted as long as it is not bind to an ENI. It is not expected for application to delete individual rules prior to deleting a group. Implementation is expected to delete/free all resources when application triggers an ACL group delete.
- ACL rules are not expected to have both tags and prefixes configured in the same rule. In case NorthBound configures with both tags and prefix, orchagent shall split this to separate rules. At high-level, requirement is an `OR` operation when there is both tag and prefix.
- ACL rules are not expected to have both tags and prefixes of same type configured in the same rule. For e.g, same Rule shall not have both src tag and src prefix configured, but it is possible to have src tag and dst prefix or vice-versa
- Counters can be attached to ACL rules optionally for retrieving the number of connections/flows. It is not required to get the packet/byte counter as in the traditional model. A new SAI counter type shall be required for this.

# 2 Packet Flows
Expand Down Expand Up @@ -544,6 +544,7 @@ DASH_VNET_MAPPING_TABLE:{{vnet}}:{{ip_address}}
"use_pl_sip_eni": {{bool}} (OPTIONAL)
"overlay_sip":{{ip_address}} (OPTIONAL)
"overlay_dip":{{ip_address}} (OPTIONAL)
"flow_resim":{{bool}} (OPTIONAL)
```
```
key = DASH_VNET_MAPPING_TABLE:vnet:ip_address ; CA-PA mapping table for Vnet
Expand All @@ -555,7 +556,8 @@ metering_class = class_id ; metering class-id
override_meter = bool ; override the metering class-id coming from the route table
use_dst_vni = bool ; if true, use the destination VNET VNI for encap. If false or not specified, use source VNET's VNI
overlay_sip = ip_address ; overlay src ip if routing_type is {privatelink}, transform last 32 bits from packet
overlay_dip = ip_address ; overlay dst ip if routing_type is {privatelink}
overlay_dip = ip_address ; overlay dst ip if routing_type is {privatelink}
flow_resim = true/false ; perform instant resimulation of flow upon mapping change; Default is set to false
```

### 3.2.10 METER
Expand Down

0 comments on commit f1bf11d

Please sign in to comment.