Re: [ovs-discuss] proactive controller utility contribution request

[Ben Pfaff]

On Mon, Feb 27, 2017 at 04:21:26PM +0100, José Luis Millán wrote:
> On Fri, Feb 24, 2017 at 6:59 PM, Ben Pfaff  wrote:
> 
> > On Fri, Feb 24, 2017 at 01:10:23PM +0100, José Luis Millán wrote:
> > > I am developing a simple utility tool that maintains connections with a
> > > list of switches and adds and removes flows on them.
> > >
> > > It's been called 'ovs-proactivecontroller' and it is inspired by
> > > 'ovs-testcontroller' utilitly, with the difference that the first does
> > not
> > > listen for connections since it is only intended to be used proactively.
> > >
> > > A new kind of switch has been created; 'passive_switch' (pswitch),
> > > analogous to the existing 'learning_switch' (lswitch), which represents a
> > > passive switch.
> > >
> > > The utility is a daemon which exposes a RPC interface via 'unixctl'
> > server
> > > with the following self explanatory API :
> > >
> > > - add_switch
> > > - del_switch
> > > - add_flow
> > > - del_flows
> > >
> > > It also accepts as startup options a file name with a list of switches as
> > > well as a file name with a list of flows. In case these options are
> > > provided, the daemon connects to the given switches at startup and
> > installs
> > > the given flows upon connection.
> > >
> > > The aim of the utility is spreading the given flows on each switch.
> >
> > To me, this sounds a lot like ovs-testcontroller with the --with-flows
> > option, with the added unixctl API.  Did you consider refining
> > ovs-testcontroller to support the unixctl API?  It would be easy to
> > accept those kinds of changes.
> >
> 
> I definitely agree.
> 
> Let me please comment a couple of points.
> 
> - switches would be added and removed based on the unixctl API as well as
> via the current command line active connection methods (ssl:ip[:port],
> tcp:ip[:port],
> unix:file)
> - ovs-testcontroller would not terminate when no more connections are
> available.
> 
> On the other hand, in lswitch_handshake (learning-switch.c) for OPF
> versions greater than 13, a flow is being installed so the switch sends
> packets to the controller by default. This is not a desirable behaviour for
> the proactive controller. How can this cleanly made? Maybe providing a
> utility option --proactive that translates into a lswitch property which is
> checked before deciding whether to install such flow or not?

I think that would be a reasonable solution.  I guess that command-line
options can be added to give ovs-testcontroller the features that you
want.  I'd be in favor of such support, if you want to provide a patch.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] proactive controller utility contribution request

[José Luis Millán]

Hello Ben,

Many thanks for your response.

On Fri, Feb 24, 2017 at 6:59 PM, Ben Pfaff  wrote:

> On Fri, Feb 24, 2017 at 01:10:23PM +0100, José Luis Millán wrote:
> > I am developing a simple utility tool that maintains connections with a
> > list of switches and adds and removes flows on them.
> >
> > It's been called 'ovs-proactivecontroller' and it is inspired by
> > 'ovs-testcontroller' utilitly, with the difference that the first does
> not
> > listen for connections since it is only intended to be used proactively.
> >
> > A new kind of switch has been created; 'passive_switch' (pswitch),
> > analogous to the existing 'learning_switch' (lswitch), which represents a
> > passive switch.
> >
> > The utility is a daemon which exposes a RPC interface via 'unixctl'
> server
> > with the following self explanatory API :
> >
> > - add_switch
> > - del_switch
> > - add_flow
> > - del_flows
> >
> > It also accepts as startup options a file name with a list of switches as
> > well as a file name with a list of flows. In case these options are
> > provided, the daemon connects to the given switches at startup and
> installs
> > the given flows upon connection.
> >
> > The aim of the utility is spreading the given flows on each switch.
>
> To me, this sounds a lot like ovs-testcontroller with the --with-flows
> option, with the added unixctl API.  Did you consider refining
> ovs-testcontroller to support the unixctl API?  It would be easy to
> accept those kinds of changes.
>

I definitely agree.

Let me please comment a couple of points.

- switches would be added and removed based on the unixctl API as well as
via the current command line active connection methods (ssl:ip[:port],
tcp:ip[:port],
unix:file)
- ovs-testcontroller would not terminate when no more connections are
available.

On the other hand, in lswitch_handshake (learning-switch.c) for OPF
versions greater than 13, a flow is being installed so the switch sends
packets to the controller by default. This is not a desirable behaviour for
the proactive controller. How can this cleanly made? Maybe providing a
utility option --proactive that translates into a lswitch property which is
checked before deciding whether to install such flow or not?

Kind regards,

-- 
--
FRAFOS GmbH

email: *joseluis.mil...@frafos.com *
www.frafos.com

Bismarckstr. 10-­12
10625 Berlin
Germany
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss

Re: [ovs-discuss] proactive controller utility contribution request

[Ben Pfaff]

On Fri, Feb 24, 2017 at 01:10:23PM +0100, José Luis Millán wrote:
> I am developing a simple utility tool that maintains connections with a
> list of switches and adds and removes flows on them.
> 
> It's been called 'ovs-proactivecontroller' and it is inspired by
> 'ovs-testcontroller' utilitly, with the difference that the first does not
> listen for connections since it is only intended to be used proactively.
> 
> A new kind of switch has been created; 'passive_switch' (pswitch),
> analogous to the existing 'learning_switch' (lswitch), which represents a
> passive switch.
> 
> The utility is a daemon which exposes a RPC interface via 'unixctl' server
> with the following self explanatory API :
> 
> - add_switch
> - del_switch
> - add_flow
> - del_flows
> 
> It also accepts as startup options a file name with a list of switches as
> well as a file name with a list of flows. In case these options are
> provided, the daemon connects to the given switches at startup and installs
> the given flows upon connection.
> 
> The aim of the utility is spreading the given flows on each switch.

To me, this sounds a lot like ovs-testcontroller with the --with-flows
option, with the added unixctl API.  Did you consider refining
ovs-testcontroller to support the unixctl API?  It would be easy to
accept those kinds of changes.
___
discuss mailing list
disc...@openvswitch.org
https://mail.openvswitch.org/mailman/listinfo/ovs-discuss