On Wed, Sep 7, 2011 at 4:37 AM, Derick Winkworth <[email protected]> wrote: > 1) Is "of1.1-spec-test" from the "OpenFlow v1.1 Implementation" page an > unofficial version of Open vSwitch that supports OF1.1? It seems to me we > could compile this and then have Q-in-Q support for Xen or Virtualbox...
To validiate[1] the OF1.1 features, we implemented some of them in OVS, but none of the features were merged together and there has been a lot of active development on OVS since then, so I'm not sure that they would be of any use to you. To say the least, none of the changes were vetted by the OVS maintainers. That said, if all you want is QinQ for OVS, my guess (just a guess, I'm not an OVS contributor) is that it's on their roadmap which could be confirmed via [email protected] . > 2)I'm sure I'm late to the game on "virtual-port" discussion but I see in > OpenFlowMPLS, OPEN-MPLS, and the v1.2 proposals page that there is the idea > of adding the ability to create virtual-ports. Is this going to be in the > next version of OpenFlow? I like this idea, it kind of makes the idea of a > separate table "whole." In a way its like a pipe. That table could be > managed separate with the "inside" properties of the virtual-port being > configurable within the context of the table (like a tenant with their own > controller) an the "outside" properties belonging to the infrastructure > provider... The real value ("hack"?) of virtual ports is that they are orthogonal to the spec, meaning you don't have to modify the specification to use them. Imagine you connect directly to the switch's CLI, run some tunnel configuration commands, and then in the OpenFlow space, a new port event is issued and the controller for all (?) intents and purposes cannot/should not distinguish between this logical tunnel port and a true physical port. That's the theory, in any case. In practice, the ASIC hardware I'm familiar with imposes additional limitations that don't apply to physical ports, so the true value of this can vary from box to box. There is also a "architecture cleanliness" issue of "aren't virtual ports a hack to get around a lack of extensibility in the spec?". I claim no and that they are in fact elegant, but there are definitely others who disagree with me. HTH, - Rob . [1] 'validate' at a spec level to see if they were implementable; due to limited engineering resources, we really didn't have time to produce production code that could have been contributed back to OVS. _______________________________________________ openflow-discuss mailing list [email protected] https://mailman.stanford.edu/mailman/listinfo/openflow-discuss
