Hi Matt,
Thank you for sharing use-cases.
For the latter case, I guess it should take some lags to change controllers
addresses on switches
to do efficiently failover.
Might have still some lags, but how about using virtual IPs on controller side
(like clustering
controller)?
I should be smaller lags than changing addresses on switch side.
Thanks,
Iwase
On 2017年10月04日 10:56, Matthew Moskowitz wrote:
Thanks Iwase and Carlos for your thoughts,
2 cases that this feature is interesting to me for would be:
Integrating Ryu with other software that is already running a different webserver/asynchronous
library. Nicer in this case not to have to deal with 2 different webservers/coroutine types.
Efficient failover if one Ryu application should fail for any reason, the new one can instantly
connect to the switch. Your suggestion to use the ovsdb library could help with this one.
Thanks,
Matt
On Tue, Oct 3, 2017 at 7:20 PM, Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>> wrote:
Hi Carlos,
Thank you for your reply!
As you said, the OpenFlow Spec does not restrict Switches must initiate
connection to Controllers.
But initiating connection by Controllers seems to be the "optional" feature.
===
Quote: OpenFlow Spec 1.3.5 "6.3.3 Connection Setup"
===
Optionally, the switch may allow the controller to initiate the connection.
In this case, the
switch should
accept incoming standard TLS or TCP connections from the controller, using
either a user-specified
transport port or the default OpenFlow transport port 6653. Connections
initiated by the switch and
the controller behave the same once the transport connection is established.
===
If OVS does not know on where Ryu is listening when OVS starting up, how
about using OVSDB library
to tell controller's IP:Port to OVS?
If OVS listening on OVSDB connection, "set-controller" API can tell its own
address to OVS.
https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc76ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128
<https://github.com/osrg/ryu/blob/6e69e9b8a6ebd2bb06aa864cc76ef0b79d1ac9c3/ryu/lib/ovs/bridge.py#L128>
And apart from that, initiating connection by Controllers looks interesting
feature for me.
Thanks,
Iwase
On 2017年10月04日 08:57, Carlos Ferreira wrote:
This is just a question, not a critic.
Doesn't the OpenFlow standard stipulates that it is the Switch that
must connect to a Controller, and not the other way around?
Carlos Ferreira
On 4 October 2017 at 00:42, Iwase Yusuke <iwase.yusu...@gmail.com
<mailto:iwase.yusu...@gmail.com>> wrote:
Hi Matt,
As far as I know, Ryu does not provide such feature (only do wait
incoming connection
like server).
Would you share us if you have any use-case or situation where Ryu
must act as a client?
If there are useful use-cases, better to implement it, I guess!
Thanks,
Iwase
On 2017年10月04日 07:16, Matthew Moskowitz wrote:
Hi,
By default when a Ryu application is started, it is listening
for a connection
request that comes from the switch. (For instance, using ovs,
you would run
ovs-vsctl set-controller to tell it where to talk to the Ryu
application). However,
OpenvSwitch can also behave like a server and wait for a
request from an openflow
controller.
Is there an existing setting that allows a Ryu application act
as a client such that
the Ryu app will make the initial request to connect with the
openflow switch?
Thanks,
Matt
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
<mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
<mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net <mailto:Ryu-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/ryu-devel
<https://lists.sourceforge.net/lists/listinfo/ryu-devel>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Ryu-devel mailing list
Ryu-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ryu-devel
