>> it implies storing of port chain and port pair group information >> as metadata Which is my concern too. While sfc is a standard use case, I see it as a variation of a customized packet flow definition. The port-pairs if defined in ovn could limit how someone can do custom traffic flows.
I am trying out customized flows by not actually punting out of pipeline but rather add a new stage called "cust_fwd" - which does forwarding to a different destination followed by "next". Similar method could be done for forwarding the L3 destination for which I use "next_hop" moniker but is currently not implemented. I do much of the processing outside of ovn to build a flow pattern and then program the logical flows using the new api I added. Considering the port-pairs are in neutron db, I think the OVN driver can do similar translation also and create a custom flow. Except there is overlap on port security and ACLs - the latter looks very similar to custom flows. But these can be pooled together. I consider ACL as one of the use cases of custom flows just as sfc is. So a custom lflow table can be potentially mapped for both ACL and SFC. Just thinking differently here. Not sure if I am missing any point, so far my code is not breaking anything other than overcoming port security. My implementation is still a long way to go, but can be seen for schema and initial flow mgmt changes. My use cases are somewhat different from sfc, so is my design. https://github.com/muraliran/ovs _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
