Added support for ACL entry netmask set with non-contiguous bits

[Pull-eckermann]

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.

[wenovus]

/gcbrun

[OpenConfigBot]

No major YANG version changes in commit 8a79b2b

[LimeHat]

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.

[robshakir]

Thanks for the PR and the research to show support on different platforms -- one note, the fact that platforms use two leaves to express address and mask does not imply that they support wildcard matches, so I'd prefer to keep these as two separate configurable entities.

+1 to comments in the thread from @LimeHat about how we implement the change -- see comments below too.

[Pull-eckermann]

@LimeHat @robshakir Breaking change removed and implemented the sugested changes. Two new leaves were added to the specific case that is of concern.

[dplore]

/gcbrun

[Pull-eckermann]

@dplore can you /gcbrun again for this PR?

[dplore]

/gcbrun