[RFE] Add a Common Flow Classifier in Neutron

[cathy Hong Zhang]

[Existing problem]
Currently, multiple Stadium features inside Neutron need flow classifier functionality. In the future there could be more Neutron features that will need this functionality. Instead of each feature creating its own FC API and resource, we should have one common FC API and resource inside Neutron that can be used by all the networking features in OpenStack (inside or outside of Neutron stadium). This will avoid a lot of redundancy and maintenance issues.

[Proposal]
Currently the features that need FC are: Tap as a service, SFC, QoS, FW, BGP/VPN, GBP. There has been a meeting discussion in the Austin Summit (https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit). The interested party has a follow-on meeting discussion on 5/17/2016 (http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html).

According to the consensus of the meeting, a new RFE for flow classifier should be submitted in neutron-core and we will develop FC as a RFE over neutron-core.

A general guideline on the FC design is that it should provide a superset of FC rules used by existing features and the FC rules should be easy to extend for new features in the future.

[Igor D.C. (igordcard)]

Thanks Cathy for filing this up.
As agreed at the meeting, let's start the details discussion here.

So, here's my formal proposal to the model of the Common Classifier (CC):

The Common Classifier model should be both explicit and extensible.
This figure shows the model proposed: [1].

Separating the traffic classification in individual types will allow future types to be added and agreed in the future, while keeping the remaining ones intact. Existing types can of course be updated and properly versioned. Looking at the neutron-classifier project, I already see hints of an architecture like this one, as can be seen in [2], so maybe there's already some interest in this approach.

So, how to define this model and how can it be used?
- The Common Classifier allows Classification Rules to be defined and used by an OpenStack service.
- 1 Classification Rule is of a single type, e.g. either Ethernet, IP, or HTTP, and contains a definition that depends on the type.
- The definition contains the fields that the type supports.
- Not all supported fields need to be defined - only the ones required by the consuming service.
- The consuming service should contain any additional logic, such as:
    - AND/ORing many Classification Rules (CRs), if needed;
    - Setting directionality constraints on the CRs, if needed;
    - Scoping the CRs to local resources (e.g. Neutron ports), if needed;
    - Other logic or local constraints.

[1] http://i.imgur.com/4reoOnB.png
[2] https://github.com/openstack/neutron-classifier/blob/10b2eb3127f4809e52e3cf1627c34228bca80101/neutron_classifier/common/constants.py#L17

[Sean M. Collins (scollins)]

You know, rather than making a whole new bug it would probably have been better to continue with the existing one, since there was already a huge amount of history and discussion.

https://bugs.launchpad.net/neutron/+bug/1583299

[Sean M. Collins (scollins)]

Sorry, https://bugs.launchpad.net/neutron/+bug/1476527

[Sean M. Collins (scollins)]

I'm going to point this back to #1476527 - spoke with Ajo about it on IRC. Let's try and avoid https://xkcd.com/927/

[cathy Hong Zhang (cathy-h-zhang)]

Based on the new consensus of people interested in this initiative (http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/2016/network_common_flow_classifier.2016-05-17-17.02.html), this feature is to be developed as a RFE over neutron-core. The old bug is positioned as a separate project on a separate repo. The recent meeting consensus is to create a new bug. With a bigger team joining the design discussion on this feature now, it seems a new spec and new codes catching the new design consensus are the way to go.