Hi Sam, Murphy,<br><br>these plans sound cool to move forward towards "polyglot" openflow libraries.<br><br>In addition to looking into the OVS ongoing work, which BTW is also advancing towards full 1.2support, I would suggest to look into two other pieces of Python code for OpenFlow that may be helpful at this point:<br>

<br>- OFTest for 1.1: <a href="https://github.com/TrafficLab/oftest11">https://github.com/TrafficLab/oftest11</a><br>- Ryu controller with OF 1.2: <a href="https://github.com/osrg/ryu/tree/master/ryu/ofproto">https://github.com/osrg/ryu/tree/master/ryu/ofproto</a><br>

<br>-Christian<br><br>On Tue, Oct 16, 2012 at 7:16 AM, Murphy McCauley <span dir="ltr"><<a href="mailto:murphy.mccauley@gmail.com" target="_blank">murphy.mccauley@gmail.com</a>></span> wrote:<br><div class="gmail_quote">

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So this isn't a complete answer, but here are some info on where *my* head is.<br>
<div class="im"><br>
On Oct 16, 2012, at 1:28 AM, Sam Russell wrote:<br>
> I've been working with a friend who's built an LSR in OpenFlow, and we're feeling the need to move to OpenFlow 1.1 and beyond. It shouldn't be too hard to implement the functional code, but I imagine that there will be some interesting design choices for handling multiple versions, and naming conventions and the like.<br>


<br>
</div>Yeah.  I've put some thought into this, but not enough that I can give really good details, but see below.<br>
<div class="im"><br>
> The first step is probably to replicate current functionality in OpenFlow 1.1 - that means the new structures for flow mods & ports.<br>
><br>
> Step two is probably MPLS - this will involve updating flow-generating functions and the like to also have fields for the MPLS tag and TC field.<br>
<br>
</div>You may have noticed that I've been doing some serious work on libopenflow (which is still in progress).  This has been a long time coming, and a lot of it is, in fact, redoing work I'd started before but never finished.  But the major reason why I'm getting back to it now is that it seems like feature-complete 1.1 in OVS is on the horizon.  This is good news for projects I'm working on, because we want MPLS.  But I want to fix up some of libopenflow's rough edges before adding significant features (and especially before splitting off a libopenflow_11), hence the recent work.<br>


<br>
The recent work is also intended to provide better support for vendor extensions -- particularly better support for OVS extensions.  In many ways, this is actually more immediately important for me than 1.1 itself, since I mostly work with OVS, OVS has a bunch of nice extensions, and I believe pretty much all 1.1 features will actually get exposed to 1.0 via OVS extensions.<br>


<br>
I think we could actually gain a lot by following OVS's approach to multiple versions of OpenFlow.  They've already done a lot of the hard work for us in terms of figuring out how the messages map between versions.  That said, my basic plan for the moment has been to copy libopenflow_01/of_01 into libopenflow_11/of_11 and hack it away until the new ones work.  For starters, I plan to use a different port number for the different protocols and have separate event loops and everything.  HOWEVER, in a number of cases, I think they can share event classes (in openflow.__init__), particularly with a little tweaking.  So that's the main gist: Separate OpenFlow implementations, but a single OpenFlow nexus which raises events from both, some of which are shared (e.g., barrier), and some of which aren't.  Another design point is being able to use connection and event objects as the appropriate protocol's namespace.<br>


<br>
The next step in the libopenflow work is to convert all the unpack methods to use the new unpacking functions. (_read, _unpack, _skip, etc.).  I think I actually have a fair amount of this done on an old fork, but it'll take some work to bring in, finish, and test.  Once that gets done, I've been planning to start pushing OVS extension stuff, which will probably entail improvements to vendor mechanisms.  After that, I think it'll be ready to split into a _11 variant.  If someone was really gung-ho on 1.1, I think the order of the last two could be swapped.<br>


<span class="HOEnZb"><font color="#888888"><br>
-- Murphy</font></span></blockquote></div><br><br clear="all"><br>-- <br>Christian<br>