On Thu, Jan 17, 2013 at 04:08:34PM -0800, Jesse Gross wrote: > On Thu, Jan 17, 2013 at 3:07 PM, Ben Pfaff <b...@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 <b...@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. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
