[ovs-dev] [PATCH 3/4] vswitchd: Add new configuration table for IPFIX collectors.

Jesse Gross jesse at nicira.com
Fri Jan 18 00:08:34 UTC 2013

On Thu, Jan 17, 2013 at 3:07 PM, Ben Pfaff <blp at nicira.com> wrote:
> On Thu, Jan 17, 2013 at 03:00:20PM -0800, Jesse Gross wrote:
>> On Thu, Jan 17, 2013 at 2:49 PM, Ben Pfaff <blp at nicira.com> wrote:
>> > On Thu, Jan 17, 2013 at 02:19:45PM -0800, Ben Pfaff wrote:
>> >> On Fri, Jan 11, 2013 at 09:55:43AM -0800, Romain Lenglet wrote:
>> > One more thing.  sFlow and NetFlow configuration work somewhat
>> > differently from IPFIX configuration.  For sFlow and NetFlow, when the
>> > admin creates the configuration in the database, then it takes effect
>> > immediately without further effort.  IPFIX doesn't work like that, if
>> > I'm reading the code correctly.  Instead, you have to add some
>> > OpenFlow actions to cause IPFIX to be sent to the collectors.  I think
>> > that's a fair way to do it, but I expect that it will surprise users
>> > who are accustomed to the way we've done NetFlow and sFlow, so I would
>> > like to document it in vswitch.xml.  It might also be worthwhile to
>> > mention it in the ovs-vsctl example, and possibly to add a FAQ entry
>> > in the Basic Configuration section.
>> Can we avoid this difference between protocols altogether?  It seems
>> like for any of the protocols it's possible to use either a standard
>> configuration (the way that we currently handle sFlow and NetFlow) or
>> an OpenFlow configuration.  That way someone could turn on IPFIX for
>> the switch or use flows to generate NetFlow, all with a common set of
>> tools.
> I think that currently NetFlow and sFlow are always active and do not
> have an option for explicit handling through OpenFlow.  It would not
> be hard, I guess, to enable IPFIX to work the same way (and maybe that
> should be the default), as long as we also allow it to work (in an
> inherently more flexible way) through OpenFlow.  But it would be
> significant work to add NetFlow and sFlow actions, and I do not know
> of users clamoring for that feature.

My hope is that we can design a single action that would work for all
of them or at least design it in such a way that it can be cleanly
extended to support other the protocols in the future.  All three
protocols are designed to solve very similar problems so having them
behave differently based on particular use cases known at various
times doesn't seem great to me.

More information about the dev mailing list