On Tue, Mar 18, 2014 at 12:07 AM, Ben Pfaff <b...@nicira.com> wrote: >> > >> > The one bit that I'm concerned about is that it allows OpenFlow 1.4 to >> > be enabled even though there are unimplemented messages that will cause >> > Open vSwitch to abort if ovs-vswitchd receives one. >> >> This was my concern too after seeing that commit where you defined >> the protocol versions as macros. >> >> > We need to avoid that somehow; one way would be to not allow >> > OpenFlow 1.4 to be enabled as long as any of those messages exist. >> >> Do you mean to disable it until all those messages are implemented ? >> It will be a while to implement all of OF 1.4. Maybe if we make it a build >> configuration option, but not sure how to do that. > > I'd be happy with a command-line option to ovs-vswitchd and ovs-ofctl.
For ovs-ofctl the user should explicitly set the OpenFlow 1.4 version with -O OpenFlow14 and this is useful for testing. We can add an additional parameter to ovs-ofctl (--alow-of14) which is by default set to false. When not set, this parameter will not allow ovs-ofctl -O OpenFlow14 to run. Regarding ovs-vswitchd, we cannot have situations where the switch will receive an OF1.4 message. This is because, at version negotiation, OFPUTIL_DEFAULT_VERSIONS is 1 << OFP10_VERSION. We think that it's safe to enable OpenFlow1.4 because this will only be noticed when the user explicitly set it with ovs-ofctl and when the Protocols fields in the database is set to OpenFlow14. Also, this can speed up development for other OpenFlow 1.4 features. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
