Hi all,
This email is primarily about choosing a preferred path to design API for
stateless filter support. There are also some related implementation questions
at the bottom.
===
Problem: we need a way to configure stateless ACL filters in OVN.
Alternatives:
1. new Stateless_Filter NB object. This approach was already prototyped in [1]
primarily with OpenShift in mind.
- pro: simplify implementation. May reduce the number of objects in
particular scenarios.
- con: yet another first order object to deal with. CMS may have to deal
with both ACL and Stateless_Filter objects.
2. reuse the existing 'allow' ACL type (comp. 'allow-related'). This approach
is discussed below.
- pro: fewer object types to deal with. No DB schema change.
- con: implementation/runtime complexity; more flows in existing stages;
backwards incompatibility due to 'allow' verb use.
Let me know if there are other concerns with reusing the 'allow' verb for the
need.
===
The (2) approach would look as follows, (quoting Dumitru)
"An alternative is to have ovn-northd automatically generate two sets of
logical flows for stateless ACLs. E.g., for all ACLs with action
"allow" and match M:
a. in the LS pipeline, stage "in/out-pre-acl", add a flow matching on M
with action "next", i.e., not setting bit REGBIT_CONNTRACK_DEFRAG, and
avoiding conntrack in the "in/out-pre-stateful" stages.
b. in the LS pipeline, stage "in-pre-lb", if there's a load balancer
configured on the LS then REGBIT_CONNTRACK_DEFRAG is set to 1. This is
already done by [2] and should remain like this for the time being.
c. in the LS pipeline, stage "in/out-acl" add a flow matching on M *but
not on conntrack hint registers* (REGBIT_ACL_HINT*) to allow the traffic
in a stateless way."
===
>From API cleanliness perspective, (2) approach seems preferable if we can keep
runtime impact in check. In OpenStack, 'stateless' is a security group rule
attribute, and they would like to avoid maintaining two separate objects for
stateless support. (There was no other example in the CMS where they would do
that, at least till now, and this would complicate their implementation.)
The backwards incompatibility of extending 'allow' verb to support stateless
filters seems acceptable, its current behavior may be considered a bug.
We'll have to measure the runtime impact of (2) approach and compare it with
(1). I am prototyping it here. Do we have tools / environments to test
the impact
of flow table changes in a set of common scenarios?
===
There's also an issue of traffic sent to conntrack twice (in ingress and
egress) due to [2], see b. in (2) approach. I am told with [3] the OVN commit
is no longer needed. How do we track minimal kernel versions supported by OVN?
===
[1]:
https://patchwork.ozlabs.org/project/openvswitch/patch/[email protected]/
[2]:
https://github.com/ovn-org/ovn/commit/64cc065e2c59c0696edeef738180989d993ceceb
[3]:
https://git.kernel.org/pub/scm/linux/kernel/git/netdev/net.git/commit/net/openvswitch/conntrack.c?id=e2ef5203c817a60bfb591343ffd851b6537370ff
===
Thanks for comments,
Ihar
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
