[ovs-dev] [PATCH] sFlow export: include standard tunnel structures (for GRE, VXLAN etc.)

[Jesse Gross]

I don't think that it's necessarily a given that the collector can see
both layers from the transit switches. As I mentioned, I see tunnels
as form of abstraction and the goal of abstraction is to simplify
things by not having to deal with the complexity of multiple layers.

What happens if you have a tenant collector? In that case it doesn't
seem desirable to see the physical information because it's not
relevant and might change (an analogue would be seeing the physical
hardware from a VM).

On Mon, Oct 7, 2013 at 10:45 AM, Neil Mckee <neil.mckee at inmon.com> wrote:
> 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 <jesse at nicira.com> wrote:
>
>> On Sun, Oct 6, 2013 at 10:11 PM, Neil Mckee <neil.mckee at 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.
>