On Nov 9, 2012, at 6:33 PM, Sam Russell wrote: > I've ported nearly all of the OpenFlow 1.0 functionality to the OpenFlow 1.1 > protocol, and it passes all of the unit tests as before except wildcarding, > but I don't care about that at the moment. In short, if you plug it into an > OpenFlow 1.1 switch, I'm fairly confident that you can set MPLS-based flows > fairly easily, meaning you can now use POX to build an open source LSR. > > I'm a wee way off full support, and have no plans for how to make it > integrate well in a dual-stack 1.0/1.1 world, but the code is all functional. > What do I need to do to get this merged back into betta?
This is great, Sam; thanks for getting started on it. I think the biggest question at the moment is whether/how much it can be integrated with the existing 1.0 stuff. My plan for a first step has been to attempt to have a separate libopenflow_02, and a separate of_02 living in the same openflow package and sharing an OpenFlowNexus. Doing this in a reasonable way is going to require changing the programming model a bit and updating all the components in the openflow package (e.g., openflow.discovery, openflow.keepalive, etc.), and ... I'm not sure whether anyone is going to like the changes or not. I've been intending to just try it out and see. Unfortunately, I probably won't have time to spend on this for another month. (Actually, I don't think we need to immediately get all the openflow components updated... for a first pass, I'd be happy with keepalive, discovery, and spanning_tree, I think. Then of_json, of_service, and webservice. Then the rest.) I'd also like to have a story for getting wildcards done. I might be able to take a look at that a bit sooner. Lastly, I'm not sure what to do about testing, but I haven't looked into it and maybe you have an idea. I don't have OF 1.1 switches, and AFAIK, Mininet/OVS aren't fully up to the task yet. Maybe they're close enough at this point as long as we don't want to use it to test out MPLS (probably fine, can be tested elsewhere) and groups (probably fine since the POX-side code isn't written for it yet anyway). > On a side note, the tests need to have a bit more comprehensive negative > testing - it's good that they can find when structs aren't the same when they > should be, but it's also important to make sure they are detected as > different. Some of the structs I've forgotten to add the new fields to the > comparison functions (and most have had it put in as an afterthought), and > negative testing would pick these up. Yeah, I agree. I'd like to automate this as much as possible (that is, not require the implementor to remember to do anything special). I'll try to keep it in mind next time I work on the tests, but feel free to propose something if you have ideas. -- Murphy
