On Feb 19, 2013, at 7:25 PM, Sam Russell wrote: > Great news! I suspect the work required to port my OF1.1 work to OF1.2 would > be similar to writing OF1.2 support from scratch based on the new > libopenflow. I'm happy to get going with that, but I'm not sure how to make > it interface with the POX code - is there a nice way to abstract away the > version of OF used underneath yet?
No, and I don't think there will be, in general -- I think this is only of really limited use for the controller side (different story for the switch side). If your application needs 1.2, then having an abstracted version isn't helpful because it can't abstract away the fact that 1.0 switches don't have 1.2 features. If your application only needs 1.0 features and you don't have all 1.2 switches -- just write the app as 1.0 and talk 1.0 to all the switches. One might argue that you could make it so that you could write your app using the 1.0 API and have POX translate and speak 1.2 to switches. Or one could argue that you could use a subset of 1.2 that corresponds to 1.0 and have POX translate to 1.0. I am not convinced that either of these is nearly valuable enough to justify (even in the case of a mix of 1.0 switches and 1.2 switches that don't implement 1.0). What may be valuable is for *events* which are mostly the same... letting you write event handlers in a protocol-agnostic way. We have kicked around some ideas for this, and they may end up getting implemented, but for the moment this seems much less useful than just getting a working libopenflow_02. So that's really my interest right now: libopenflow_02. I think we can temporarily hack up whatever it takes to get it working (e.g., of_02), and worry about integrating things a little more nicely when we're a bit further down the road. -- Murphy
