yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #89886
[Bug 1476527] Re: [RFE] Add common classifier resource
Bug closed due to lack of activity, please feel free to reopen if
needed.
** Changed in: neutron
Status: Triaged => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1476527
Title:
[RFE] Add common classifier resource
Status in neutron:
Won't Fix
Bug description:
[Existing problem]
Currently, in neutron each service/s which requires a classifier implements the same of their own. This introduce lot of redundancy and maintenance issues.
[Proposal]
In order to address the above problem, the specification [1]_ introduces a common classifier resource for Neutron.
[Benefits]
- The new resource can be leveraged to better realize other Neutron services needing traffic classification. Traffic classification is commonly needed by many Neutron services (e.g. Service Function Chaining [2]_, QoS [3]_, Tap as a Service [4]_, FWaaS [5]_, Group-Based Policy [6]_, and Forwarding Rule [7]_), but each service uses its own classifier resource similar to others. A common traffic classifier resource should exist in Neutron so that it could be leveraged across network services avoiding redundancy and maintenance issues.
- We can also think of deploying a classifier independently for any service/s, which does classification at the ingress/egress. In turn, the services will solely be responsible for their required work.
Example: For Service Function Chaining, flow classifier could be implemented by Neutron while the service chaining can be done by the third party ML2 plug-in.
- Comparison between this proposal with the exiting one's is also captured [9]_.
[What is the enhancement?]
- Add traffic classifiers to Neutron API as extension.
- Classifier can be independently deployed at the ingress/egress without depending upon any of the service/s.
- In future, we can also think of extending the same interface for filtering routes which might be required for other ongoing work like BGP dynamic routing [8]_ happening in Neutron in the Liberty release.
[Related information]
[1] Specification
https://review.openstack.org/#/c/190463/
[2] API for Service Chaining,
https://review.openstack.org/#/c/192933/
[3] QoS,
https://review.openstack.org/#/c/88599/
[4] Tap as a Service,
https://review.openstack.org/#/c/96149/
[5] Firewall as a Service,
http://specs.openstack.org/openstack/neutron-specs/specs/api/firewall_as_a_service__fwaas_.html
[6] Group-based Policy,
https://review.openstack.org/#/c/168444/
[7] Forwarding Rule,
https://review.openstack.org/#/c/186663/
[8] Neutron route policy support for dynamic routing protocols
https://blueprints.launchpad.net/neutron/+spec/neutron-route-policy-support-for-dynamic-routing-protocol
[9] Details about common classifier and it's comparison with SG and other's
https://etherpad.openstack.org/p/flow-classifier
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1476527/+subscriptions
References