On Jan 17, 2013, at 4:08 PM, Jesse Gross <je...@nicira.com> 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.
The only practical detail to solve would be to choose an appropriate observation point ID for samples that are not sampled by controller-specified sample actions, which all have controller-specified IDs. We could decide that those samples have no observation point ID. That would require defining extra templates without any observation point ID field, which would double the number of templates. The size of the template set is already > 700 bytes, so we would have to send template records in two UDP packets instead of one to prevent going over usual MTU limits. That doesn't seem like a good idea. > 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 don't think it would be possible. Those protocols are actually quite different. IPFIX specifies the observation point ID field, which I need to specify a controller-specified ID associated with samples. The existence of that field is the only reason I needed to implement IPFIX. There are no such fields in NetFlow v5 or sFlow. How would you reconcile that difference into a single OpenFlow action? -- Romain Lenglet _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
