Re: [ovs-dev] [RFC] [PATCH] ovn: Support sample action in logical datapath
On 30.11.2016 06:18, Ben Pfaff wrote: 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. Running collectors local to hypervisors is what we do here. I can't say if it's a common scenario, but given that IPFIX is most often UDP which can be lost, it usually makes sense to keep collectors and exporters as close as possible. 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? You mean using an lflow match to control when the "sample" action will trigger, rather than hard-wiring these actions to logical ports via "ipfix_options"? This sounds reasonable and not to hard to implement, given that we already have these tables in the southbound db. 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? No, no prior discussion, sorry for being unclear. I was referring to your concerns regarding CMS integration in the beginning of this thread. Thanks, Valentine ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] [PATCH] ovn: Support sample action in logical datapath
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. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] [PATCH] ovn: Support sample action in logical datapath
Hi Ben, 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. Does the approach I take looks sensible? If so, I can add tests and re-send this patch for in-depth review. Many thanks. Signed-off-by: Valentine Sinitsyn Sorry about the long delay in review. It's been a difficult month. No problem. 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? 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. 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? I hope that the long delay does not discourage you from following up. I hope to be more responsive now. Sure, I'm open for the discussion. Thanks, Valentine ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
Re: [ovs-dev] [RFC] [PATCH] ovn: Support sample action in logical datapath
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. > > Does the approach I take looks sensible? If so, I can add tests and re-send > this patch for in-depth review. > > Many thanks. > > Signed-off-by: Valentine Sinitsyn Sorry about the long delay in review. It's been a difficult month. 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. Do you have any thoughts about supporting other monitoring technology that OVS supports (e.g. sFlow) using similar techniques? I hope that the long delay does not discourage you from following up. I hope to be more responsive now. ___ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
