> From: [email protected] 
> [mailto:[email protected]] On Behalf Of Darrell Ball
> Sent: Thursday, 30 November, 2017 01:15
> 
> On 11/27/17, 11:31 AM, "Ben Pfaff" <[email protected]> wrote:
> 
>     Darrell, I think that you are working on some of the specific items that
>     Aaron listed.  Can you comment on that?
> 
> 
> “1”: which is day 1 behavior, has been discussed on other threads on the 
> mailing list for some weeks.  I submitted a patch
>        that would be used, if it were to have been brought in sync. However, 
> after further discussions, I realize that just
>        auto-matching the kernel is not a requirement and people share 
> separate concerns with this approach, in general.  Hence,
>        in this case, we can go with the better technical option and leave the 
> userspace conntrack EST as is, since everyone recognizes it
>        is semantically correct. I will update the documentation with 
> suggested usages. We can always revisit if we find differences
>        w.r.t. real/proper conntrack pipelines.
>

I am afraid we do not agree to the statement that everyone recognizes the 
userspace conntrack semantics for EST state as semantically correct. What does 
correct mean here?

The current behavior certainly deviates from the behavior of the OVS kernel 
conntrack (as documented e.g. in 
http://www.iptables.info/en/connection-state.html). The OVS documentation for 
ct_state in http://openvswitch.org/support/dist-docs/ovs-fields.7.pdf matches 
neither kernel nor userspace conntrack behavior.

We would clearly prefer to align the conntrack semantics of all OVS datapaths 
(kernel, netdev, windows) and specify that behavior in an unambiguous way in 
the OVS documentation. Anything else is likely to create compatibility issues 
when SDN controllers need to control OVS bridges with different backing 
datapaths. The entire discussion was triggered by an incompatibility detected 
when OpenDaylight Netvirt moved from OVS kernel to DPDK datapath.

If the OVS community cannot agree on uniform semantics, then OVS must at least 
explicitly document differences in behavior so that controller developers have 
the chance to limits themselves to conntrack pipeline configurations that stay 
clear of such discrepancies.

Regards, Jan
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to