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

Ben Pfaff blp at nicira.com
Fri Jan 18 00:10:10 UTC 2013

On Thu, Jan 17, 2013 at 04:08:34PM -0800, Jesse Gross wrote:
> 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.

I agree that that would be ideal.

More information about the dev mailing list