[ovs-dev] [RFC] [PATCH] ovn: Support sample action in logical datapath

[Ben Pfaff]

On Tue, Nov 29, 2016 at 07:22:32PM +0500, Valentine Sinitsyn wrote:
> On 29.11.2016 05:21, Ben Pfaff wrote:
> >On Fri, Oct 14, 2016 at 04:35:46PM +0500, Valentine Sinitsyn wrote:
> >>This is a quick attempt to implement sample action at logical port
> >>level.The goal is to export IPFIX flows for logical ports, yet it is
> >>easy to extend this approach to logical switches as well.
> >>
> >>Nothing is done to provision OVS instances with required
> >>Flow_Sample_Collector_Set and IPFIX entries at this point.
>
> >This is pretty cool!  The integration among OVS and OVN and IPFIX is
> >graceful.
> >
> >The part that worries me is the CMS integration.  Have you actually
> >built that integration already (for which CMS)?  I have two concerns.
> >First, I'd prefer to see at least one CMS (probably OpenStack) support
> >this at or around the time that it goes into OVN.  Second, I have some
> >skepticism around the idea that the CMS should configure the
> >Flow_Sample_Collector_Set, etc., because OVN doesn't currently require
> >the CMS to have any connectivity to OVSDB on each of the hypervisors and
> >this would require the CMS to add that support.
> I agree that this particular bit is somewhat hacky. We plan to follow this
> route for an in-house CMS we build, but I doubt OpenStack community would
> pickup the idea. What alternatives do you see here? Having collector config
> at south db level doesn't seem clear either. Think I want to configure
> collector at 127.0.0.1:5900 - which localhost does this entry refer to?

Is this a common way to configure IPFIX?  I had been under the
impression that generally there's one or a few collectors in a network,
to which each switch forwards packets.  If it's common to use a
per-hypervisor collector, then that might actually makes thing easier,
since that would be easy for ovn-controller to configure into OVS on
each hypervisor.

Otherwise, I'm inclined to at least learn what the requirements would be
for common deployments of IPFIX.  Even if we don't implement it them (or
all of them), it's important to me to know what we're leaving out so
that what we add now is built in a way that it's gracefully extensible
later.

For example: if a packet should be sent to a collector, should the
collector be chosen based on the packet's logical network, or based on
the packet's physical network (the hypervisor it's ingressing or
egressing), or on some combination of those?

I also find myself wondering whether logical port level is the right
level at which to choose whether to sample packets.  Will OVN users want
finer-grained control over sampling and, if so, would it make more sense
to add an ACL-like table for that purpose at the northbound level?

> If the sample() integration looks good, CMS assumptions aside, is there a
> chance to merge it as a stand-alone action? That's true no publicly
> available CMS would use it for a while, but when they decide to, the code
> would already be there. And the code is not dead, as we'll be using it as
> well.

It's better than no users at all.

> >Do you have any thoughts about supporting other monitoring technology
> >that OVS supports (e.g. sFlow) using similar techniques?
> I haven't targeted any of them specifically, but it doesn't seem to be a
> daunting task. One only need some way to associate sample() instance and a
> sFlow receiver the same way collector_set_id does for IPFIX.
> 
> I'd suggest to generalize Flow_Sample_Collector_Set somehow, but we agreed
> configuring things through this table in OVN scenario is suboptimal. Any
> thoughts?

Did we have an earlier discussion?  I've spent a few minutes searching
my email archive and I don't see one.  If there was one, can you point
it out?

Thanks,

Ben.