Gentlemen,

... snip snip...
On 2018-03-09 01:40, Mahesh Jethanandani wrote:
Choice of source port definition using range/operator or referring to a group of source ports, to be added as a future 'case' statement.

 - ditto for "or referring to a group of destination ports."
 - ditto on both of the above for the "udp" container
 - is it possible for both "egress-interface" and "ingress-interface" leafs to    be specified at the same time?  - if not, should there a 'must' statement to    prevent that possibility? - or an explanation for what happens if it occurs?

Let me discuss this with my co-authors.

It is possible to match both egress-interface and ingress-interface in the same ACL. Different devices support different type of attachment points for ACLs. Most routers, like an ASR9k or Juniper MX, supports attaching ACLs on interfaces in either ingress or egress direction. If we apply ACL FOO ingress on interface BAR then it would perhaps be weird to use the ingress-interface match in the FOO ACL since ingress-interface will always be BAR for every packet evaluated. Using egress-interface would make a lot more sense (and we will know the egress-interface if the platform performs the route lookup before evluating the ACL which is an implementation issue). We could introduce a must constraint to avoid a silly situation but I don't think that's a real improvement on the model.

Above all, considering the other type of attachment, which we find among others on Linux with iptables or nftables, which is a sort of "global" attachment point, it makes sense to be able to specify both. nftables rules are not written and attached to a particular interface but rather end up in a central list of rules and so it makes sense being able to write individual rules that match on ingress-interface, egress-interface or both (or none). A must constraint would make that impossible, so please don't add a must.

Kind regards,
   Kristian.

_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to