openconfig
Manage prefix list and extend ACLs to match prefix lists in source/destination
The proposal is to extend the ACL model to be able to match source/destination address vs a prefix list (currently only individual matching is possible). In adition, the prefix-lists are maintained. Note that the prefix lists are different from the routing policiy prefix lists.
Tree of the proposal:
module: openconfig-acl-defined-sets
+--rw defined-sets
+--rw config
+--ro state
+--rw ipv4-prefix-sets
| +--rw ipv4-prefix-set* [name]
| +--rw name -> ../config/name
| +--rw config
| | +--rw name? string
| | +--rw description? string
| | +--rw prefix* oc-inet:ip-prefix
| +--ro state
| +--ro name? string
| +--ro description? string
| +--ro prefix* oc-inet:ip-prefix
+--rw ipv6-prefix-sets
| +--rw ipv6-prefix-set* [name]
| +--rw name -> ../config/name
| +--rw config
| | +--rw name? string
| | +--rw description? string
| | +--rw prefix* oc-inet:ip-prefix
| +--ro state
| +--ro name? string
| +--ro description? string
| +--ro prefix* oc-inet:ip-prefix
+--rw port-sets
+--rw port-set* [name]
+--rw name -> ../config/name
+--rw config
| +--rw name? string
| +--rw description? string
| +--rw port* oc-pkt-match-types:port-num-range
+--ro state
+--ro name? string
+--ro description? string
+--ro port* oc-pkt-match-types:port-num-range
The sets are called within the ACLs
References:
- Nokia: Match list for Filter policies
- https://documentation.nokia.com/html/0_add-h-f/93-0073-HTML/7750_SR_OS_Router_Configuration_Guide/filterscli.html
- Cisco: Prefix lists for ACLs
ipv4 prefix-list pfx_1
- https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/asr9k_r4-1/addr_serv/configuration/guide/ipaddr_cg41a9k_chapter1.html#task_1061539
- https://www.cisco.com/c/en/us/td/docs/routers/ncs6000/software/ncs6k_r6-1/add-ser/configuration/guide/b-ncs6000-ip-addreses-configuration-guide-61x/b_ipaddr_cg50ncs_chapter_01.html
My comments below are similar to Rob:
- a single prefix-list should only include IPv4 prefixes or IPv6 prefixes, not both
- to solve this we can have 2 different list such as ipv4-prefix-set and ipv6-prefix-set to re-use the existing terminology, that is what most system use today (a type within the list for IPv4 or IPv6 is I suppose another option).
- both source-address-prefix-list and destination-address-prefix-list should be supported as match criteria for IPv4 and IPv6
- is there a reason to use ipv4-prefix-set terminology vs ipv4-prefix-list?
Note: a source-address-prefix-list match would be mutually exclusive internally with a source-address match within the same filter entry (same for destination-address and destination-address-prefix-list)
My comments below are similar to Rob:
- a single prefix-list should only include IPv4 prefixes or IPv6 prefixes, not both Oscar: Agree, let's go with two separated lists, one for IPv4 prefixes, and another one for IPv6 prefixs.
- to solve this we can have 2 different list such as ipv4-prefix-set and ipv6-prefix-set to re-use the existing terminology, that is what most system use today (a type within the list for IPv4 or IPv6 is I suppose another option). Oscar: Better two lists and remove the type, one parameter less to configure :-)
- both source-address-prefix-list and destination-address-prefix-list should be supported as match criteria for IPv4 and IPv6 Oscar: Yes, I just started with one for simplicity. Let's have both. @phil-bergeon @robshakir Do you think we need a generic address that matches either source or destination? or we keep just source and destination?
- is there a reason to use ipv4-prefix-set terminology vs ipv4-prefix-list? Oscar: The terminology somehow came inherited from the prefix-set in routing policies... Prefix list is also perfectly fine. In fact, in Telefonica, people talk about prefix lists and not sets.. So.. @robshakir do you prefer one over the other?
Note: a source-address-prefix-list match would be mutually exclusive internally with a source-address match within the same filter entry (same for destination-address and destination-address-prefix-list) Oscar: You are right. The only way to solve it is to allow either source address or source-address-prefix-list in the same list. The problem is, currently:
leaf source-address {
type oc-inet:ipv4-prefix;
description
"Source IPv4 address prefix.";
}
This should be changed from type oc-inet:ipv4-prefix to a choice and that change is NOT backwards compatble....
Hi, almost there for a complete model. You should add destination for ipv4 as well as source and destination for ipv6.
Commit https://github.com/openconfig/public/pull/649/commits/669666de69716b62639ddc06892c5f765008637a adds the support for ipv6 prefix source and destination sets, as well as the ipv4 destination set.
Question regarding the Cisco reference here, if the intention is to show multiple vendor implementations of an alternative syntax for acl's used for filtering (intentionally not used for bgp filtering purposes), I believe that prefix-lists are a misleading example.
Am I correct to think that a more equivalent match for this would be object-groups?
https://www.cisco.com/c/en/us/td/docs/routers/asr9000/software/ip-addresses/command/reference/b-ip-addresses-cr-asr9000/b-ipaddr-cr-asr9k_chapter_01.html#wp3145726977
@oscargdd please update the PR description (the first comment in this PR) to provide the operational use case for this model. Please contrast with the acl-sets proposed in #693
@oscargdd please update the PR description (the first comment in this PR) to provide the operational use case for this model. Please contrast with the acl-sets proposed in #693
Done! The operational use case is described.
Last call for comments! This PR is scheduled to be merged on December 14, 2022.
@rgwilton @rolandphung @earies @hellt
I have received via email the following comment via email, that I reproduce here:
We suggest to change the type of the address leaf, there is no need to keep it as ip-prefix (union). Instead, it should be ipv4-prefix and ipv6-prefix as the ipv4 and ipv6 container are separate. Note that some someone else has already mentioned that in the comment section in Git.
+--rw ipv4-prefix-sets | +--rw ipv4-prefix-set* [name] | +--rw name -> ../config/name | +--rw config | | +--rw name? string | | +--rw description? string | | +--rw prefix* oc-inet:ip-prefix. >>>> should be ipv4-prefix and ipv6-prefix respectively.
I have done a last pass to ensure consistency in naming. Now we are using “set” in the defined-set container and list in the matches. So .. I think we should stick to one (even for me both set and list mean the same…). There was a comment by Rob on replacing list with set for one part of the code, so by now I’ve extended it to be consistent across all the PR. Let me know if you have any issue with using "set" across the PR.
I’ve got a question on the folder naming. We started naming it openconfig-acl-defined-sets, but the containter is just defined-sets, as we agreed on being generic so sets could be used for more things. So… should we remove the acl in the folder name?