I agree that the timing is good for FWaaS to look at the possibility of using a common traffic classifier in the new FWaaS 2.0 API. If we can agree on a definition and get moving on an implementation in the Mitaka time frame, we could avoid a painful API migration later on. Sean has started moving us down this path with his proposal for a common classifier database. Assuming that we move in this direction, the service groups feature would be aimed at the common traffic classifier rather than the FWaaS API itself.
Although various features such as QoS, FWaaS, security groups, SFC want to do traffic classification based on similar parameters such as source and destination IP address, protocol, source and destination L4 port, etc, there are different ways to structure this information. Through grouping and indirection, we can structure the model so that only experts deal with IP addresses and L4 ports, while users reference reusable groups. Thinking about sharing and reuse, it makes sense to break the classification parameters into two parts: identity (including source and destination IP address, source and destination MAC address), and service (protocol, source and destination L4 ports, L7 parameters). Perhaps QoS related parameters and encapsulation related parameters would add more parts. Service groups are not aimed at the entirety of traffic classifier, they are aimed at only the service part of the traffic classifier. A tenant may be running the same application in several places. In these different places, the identity parameters will vary, but the service parameters (protocol, source and destination L4 ports, L7 parameters) will be the same. One expert could define a service group for a particular application, then multiple users could reference those service groups as they roll out that application in different places in the cloud. The expert could be someone within the tenant's organization, or it could be a service provider admin. To address this later case, we should introduce the notion of shared service groups, typically defined by the admin but used by different tenants. For some applications, there may be multiple sets of L4 ports that must be allowed. This is addressed through the grouping aspect of service groups. In the future, as deep packet inspection comes into the picture, the service can be identified through application ID rather than or in addition to L4 port. This would involve enhancements to the L7 parameters within service groups. The indirection through service groups would isolate this change from the base traffic classifier itself. Note that security groups and service groups are different things, aimed at different aspects of traffic classification. Security groups are aimed at the identity part of the traffic classifier, allowing users to refer to groups of Neutron ports rather than having to replicate rules over and over again for different IP addresses. Service groups are aimed at the service part of the traffic classifier, allowing users to refer to application-related service groups rather than having to specify L4 ports. For the upcoming FWaaS 2.0 API, we will want traffic classification using both the notions of security groups (generalized to get away from existing connotations of the term "security group") and service groups. I hope that we can agree on a common traffic classifier built on these concepts. Mickey -----Jay Pipes <jaypi...@gmail.com> wrote: ----- To: openstack-dev@lists.openstack.org From: Jay Pipes <jaypi...@gmail.com> Date: 11/09/2015 05:04AM Subject: Re: [openstack-dev] [neutron][qos][fwaas] service groups vs. traffic classifiers On 11/03/2015 12:19 PM, Ihar Hrachyshka wrote: > Now, I don't think that we need two APIs for the same thing. I would > be glad if we instead converge on a single API, making sure all cases > are covered. In the end, the feature is just a building block for > other features, like fwaas, security groups, or QoS. > > We could build traffic classifier use cases on top of service groups, > though the name of the latter is a bit specific, and could use some > more generalization to cover other cases where we need to classify > traffic that may belong to different services; or vice versa, may > split into several categories, even while having a single service source. > > I encourage those who work on traffic classifier, and those who will > implement and review service group feature, to start discussion on how > we converge and avoid multiple APIs for similar things. +1000 Please do not create 3 APIs that essentially do the exact same thing. I think Sean's on the right track with the modeling he's been doing in his PoC library. I think the classifier spec from Yuji Azama is better than the networking-sfc service function chaining API proposal because, well, it actually describes an API instead of a series of CLI commands. The problem with the classifier proposal, though, is that it flattens the API into just the rules part, discarding the grouping part that allows one to define groups of rules. The service-group[-rules] spec gets this part correct. At this point, I'd recommend just enhancing the existing security-group and security-group-rules APIs, though, since having both "service-group" and "security-group" in the API referring to similar concepts will be quite confusing IMHO. But then, Sean has told me he doesn't want to change the original AWS security group concept in the Neutron API... I'm on the fence about whether that would really be problematic if the security-group[-rules] API is enhanced/evolved appropriately. In short, my preference, in order, would be: 1) Enhance/evolve the existing security-groups and security-group-rules API in Neutron to support more generic classification of traffic from L2 to L7, using mostly the modeling that Sean has put together in his PoC library. 2) Keep the security-group API as-is to keep outward compatibility with AWS. Create a single, new service-groups and service-group-rules API for L2 to L7 traffic classification using mostly the modeling that Sean has put together. Remove the networking-sfc repo and obselete the classifier spec. Not sure what should/would happen to the FWaaS API, frankly. Best, -jay __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
