openconfig
Added support for ACL entry netmask set with non-contiguous bits
Added support for ACL entry netmask set with non-contiguous bits
This pull resquest is being created in the context of issue 1082
In the current OpenConfig, configuration of source-address and destination-address leaves in the /oc-acl:acl/acl-sets/acl-set/acl-entries/acl-entry/ipv4/config (or ipv6) xpath are only supported with netmasks that are left-contiguous, cause this leaves are defined with type oc-inet:ipv4-prefix or oc-inet:ipv6-prefix, which only allows CIDR mask format.
The contiguous mask is applicable when assigning an IP address to an interface, or while adding routes. However, it does not necessarily need to be contiguos for ACLs. ACL's should be capable of filtering based on any kinds of masks. This way multiple non consecutive ranges of networks can be covered in one shot.
Change Scope
- Changed type of source-address and destination-address leaves (ipv4 and ipv6) to oc-inet:ipv4/6-address. Also created new leaves to represent the netmask for each address, allowing CIDR format or wildcard bits.
- Type of source and destination address were changed but this change is backwards compatible.
Platform Implementations
- For CISCO, documentatin of this type of configuration can be found here in "Wildcard Mask for Addresses in an Access List" section. Also, in the file (Cisco-IOS-XE-acl.yang)[https://github.com/YangModels/yang/blob/main/vendor/cisco/xe/1791/Cisco-IOS-XE-acl.yang] there is an example in grouping ipv4-acl-src-dst-addr-port-grouping, line 1019, were ipv4-address and mask are separated in two leaves.
- Ipinfusiuon OcNOS implements this in the yang ipi-acl-types.yang with the typedef acl_any_ipv4_src_addr_t (line 244), as a union.
- JUNO OS from Junyper also have support to this, docs can be found here in "Understanding Wildcard Addresses" section.
- FortiOS from Fortinet also have support to this and an example is found in this page.
- Huawei documentation about this can be found here in Table 1-4.
No major YANG version changes in commit 8a79b2bb118859f56a3f52271136f2f681332cac
I'd prefer to see new leafs added instead of changing the existing source-address/destination-address.
Changing the type is a major, breaking change and, in my opinion, is not warranted in this case.
@LimeHat @robshakir Breaking change removed and implemented the sugested changes. Two new leaves were added to the specific case that is of concern.
