Jump to: navigation, search

Difference between revisions of "Neutron/CommonFlowClassifier"

(IRC Discussion Meeting Information)
Line 1: Line 1:
= IRC Discussion Meeting Information =
+
= Engaging in the effort =
Every two weeks (on even weeks) on Tuesday at 1400 UTC in #openstack-meeting (since 21st March 2017, so don't use earlier dates as reference for future dates).
 
  
= Meetings =
+
The Common Classification Framework is an ongoing effort to bring a common traffic classification API and framework to Neutron. As of now, there is a spec at https://review.openstack.org/#/c/333993 and PoC code based on openstack/classifier at https://review.openstack.org/#/c/445577/.
 +
If you want to join us, please help us by reviewing these artifacts, suggesting your ideas and showing your use cases. We are also happy to accept technical contributions as well, as the initial piece of code lands.
 +
 
 +
= IRC Meetings =
 +
 
 +
Every two weeks (on even weeks) on Tuesday at 1400 UTC in #openstack-meeting (since March 21st 2017, so don't use earlier dates as reference for future dates).
  
 
Previous Meeting Logs
 
Previous Meeting Logs

Revision as of 15:06, 21 March 2017

Engaging in the effort

The Common Classification Framework is an ongoing effort to bring a common traffic classification API and framework to Neutron. As of now, there is a spec at https://review.openstack.org/#/c/333993 and PoC code based on openstack/classifier at https://review.openstack.org/#/c/445577/. If you want to join us, please help us by reviewing these artifacts, suggesting your ideas and showing your use cases. We are also happy to accept technical contributions as well, as the initial piece of code lands.

IRC Meetings

Every two weeks (on even weeks) on Tuesday at 1400 UTC in #openstack-meeting (since March 21st 2017, so don't use earlier dates as reference for future dates).

Previous Meeting Logs

http://eavesdrop.openstack.org/meetings/network_common_flow_classifier/

Discussion Topic 21 March 2017

  • PoC status
  • Open discussion

Discussion Topic 28 February 2017

  • Post-PTG summary
  • PoC status
  • Next steps for the CCF
  • Open discussion

Discussion Topic 14 February 2017

  • Approach A - PoC status
  • PTG information
  • Open discussion

Discussion Topic 17 January 2017

  • Approach A - PoC status
  • Open discussion

Discussion Topic 6 December 2016

  • Continue discussion on user-facing API vs. Classification mixins.
  • Call for contributors
  • Open discussion

Discussion Topic 22 November 2016

Discussion Topic 11 October 2016

Classification Framework

OVS Flow Management

Open discussion

Discussion Topic 27 September 2016

Classification Framework

OVS Flow Management

Open discussion

Discussion Topic 5 July 2016

Discussion Topic 14 June 2016

Discussion Topic 17 May 2016

Meet-up Discussion Notes

Austin Summit Etherpad discussion notes

https://etherpad.openstack.org/p/Neutron-FC-OVSAgentExt-Austin-Summit

Atlanta PTG main whiteboard drafting

https://drive.google.com/open?id=0B41O7G76VLRpS1VpMW1wZmhVOGs

Overview

Multiple Stadium features inside Neutron need flow classifier functionality. Instead of each feature creating its own FC API, we should have one common FC API that can be used by all the features. Currently the features that need FC are: Tap as a service, SFC, QoS, Security Group, FW, BGP/VPN. Following are some general guielines on the FC API specification: ---Common FC API should not cause a major change of existing FC API used by the features, and should be a superset of existing FC rules used by existing features ---We should come up with one consistent way of defining the API and classification rules, and then associate the FC with each feature.

Currently only networking-sfc and security group have defined and implemented the FC API.

1. First step is to identify the gap between the security group FC API and the networking-sfc FC API. Following is the comparison table and the gap. It seems the SFC FC is superset of security group FC.

Neutron Common Classifier.png

2. Second step is to consolidate the two FC into one. Two options: 1) evolve the SFC FC to be the common FC for Tap as a service, SFC, QoS, Security Group, FW, BGP/VPN, 2) evolve the SFC FC to be the common FC for Tap as a service, SFC, QoS, FW, BGP/VPN, but keep the security group separate.

3. Write a spec on the consolidated FC and get it reviewed and consensus reached.

Contributors