← Back to team overview

yahoo-eng-team team mailing list archive

[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