Thanks for the prompt reply. If the external sFlow analyzer always knows the difference between the outer (tunnel) and inner (tenant) layers, then it can present the appropriate abstraction depending on the application. It can already see both layers from sFlow-enabled transit switches in the fabric, so this patch is just filling out the picture.
For example, (1) a routing application might only care to know the tunnel flows, (2) a user-billing application might want to pull out the tenant traffic matrix and (3) a congestion-controller might want both so it can alleviate congestion somewhere (perhaps using selective dscp-marking). The external sFlow analyzer(s) can supply each with the data they need. So I don't see why you would ever want to turn the tunnel info off? As soon as there is an option to turn it off then every consumer of the data would always have to worry that the outer traffic matrix was being polluted with tenant address-space, and manage the resulting state-explosion on both the configuration and the analysis side. Better to have no option. Neil On Oct 7, 2013, at 9:47 AM, Jesse Gross <je...@nicira.com> wrote: > On Sun, Oct 6, 2013 at 10:11 PM, Neil Mckee <neil.mc...@inmon.com> wrote: >> Please comment on this proposed patch. It adds the standard >> sFlow-TUNNEL structures to the sFlow export, which will be helpful >> for tracing tunneled traffic through a network fabric in real-time. > > Is there a way to turn this off? Since tunnels are designed to provide > a layer of abstraction, it's not clear that it is always desirable to > expose this information. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
