Hi Victor,
Yes, same Jeronimo from FIU! ;)
Thanks for your comments. Let me reply inline:
2016-04-25 9:44 GMT-04:00 Victor Orlikowski <[email protected]>:
> Jeronimo,
>
> Long time since we met in person, at the I2 gathering (presuming you're
> the same Jeronimo from FIU). ;)
>
> Am I correct in presuming that you're trying to making a OF
> version-adapting proxy?
>
Yes. As you know, our project migrated our network to OpenFlow 1.0 in 2014,
and since then, we use Internet2's OESS+NOX+FSFW. We would like trying new
stuff with OpenFlow 1.3, but we don't want to change OESS.
> A la FlowSpace Firewall or Flowvisor, but capable of translating from one
> version of OF to another (so that equipment supporting *only* a newer
> version of OF can be supported by a controller only supporting an older
> version of the specification)?
>
Exactly. So, my plan is to develop something simple enough that I could
keep using OESS while adding new white boxes (with OF1.3 only) to our
network.
>
> Reason I ask:
> 1) In my experience, *most* switch OF agents supporting newer revisions of
> the spec also support older versions, and *tend* to properly negotiate down
> to the mist recent revision of the spec that both the controller and the
> agent support.
> I have encountered a switch vendor or two whose switches did not do this
> spec-mandated auto-negotiation correctly - but that was due to bugs in the
> firmware, which were quickly resolved.
>
That's a good point. I haven't tried yet, but Corsa says they only support
OF 1.3. I will try.
> 2) In trying to attempt a translation between OF 1.0 and any newer
> revisions of the spec - a switch implementing a newer version of the spec
> would have to implement only a single flow table, as OF 1.0 has no concept
> of multiple flow tables (as introduced in revision 1.1 of the spec).
> Otherwise, you start to run into a very complex situation, that will
> require switch capability matching - and rule translation based on that
> capability matching - on a per-switch basis.
Yes, that's true, but this situation is temporary (it always is, right?
;)). We just want to experiment new vendors with OF1.3 only.
So, do you think I should purse this approach?
Thanks for your time! See you at Global Summit?
Jeronimo
>
> Hope that helps,
> Victor
> --
> Victor J. Orlikowski <> vjo@[cs.]duke.edu
>
> > On Apr 25, 2016, at 9:23 AM, Jerônimo Bezerra <[email protected]>
> wrote:
> >
> > Thanks. What would be the best way for Ryu to connect to another
> OpenFlow controller, also via OpenFlow? Create a standard TCP socket and my
> code be responsible for all OpenFlow commands or is there a way for Ryu to
> start an OpenFlow/TCP channel natively?
> >
> > My idea is:
> >
> > OF switch connects to Ryu with 0F1.3 - Ryu connects to a third party
> OpenFlow controller with OF.10.
>
------------------------------------------------------------------------------
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z
_______________________________________________
Ryu-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/ryu-devel
