Correcting networking-odl to mitaka/stable + app topology patch

Change-Id: Iddcd8dda2d49fcdd8e0f37a1d052a6fa8a24b035
Signed-off-by: Wojciech Dec <wdec@cisco.com>

9 files changed, 138 insertions, 586 deletions

diff --git a/networking-odl/doc/source/devref/hostconfig.rst b/networking-odl/doc/source/devref/hostconfig.rst
deleted file mode 100644
index 70c8607..0000000
--- a/networking-odl/doc/source/devref/hostconfig.rst
+++ /dev/null
@@ -1,119 +0,0 @@
-Host Configuration
-==================
-
-Overview
---------
-
-ODL is agentless configuration. In this scenario Host Configuration is used
-to specify the physical host type and other configurations for the host
-system. This information is populated by the Cloud Operator is in OVSDB in
-Open_vSwitch configuration data in the external_ids field as a key value pair.
-This information is then read by ODL and made available to networking-odl
-through REST API. Networking-odl populates this information in agent_db in
-Neutron and is then used by Neutron scheduler. This information is required
-for features like Port binding and Router scheduling.
-
-Refer to this link for detailed design for this feature.
-
-https://docs.google.com/presentation/d/1kq0elysCDEmIWs3omTi5RoXTSBbrewn11Je2d26cI4M/edit?pref=2&pli=1#slide=id.g108988d1e3_0_6
-
-Related ODL changes:
-
-https://git.opendaylight.org/gerrit/#/c/36767/
-
-https://git.opendaylight.org/gerrit/#/c/40143/
-
-Host Configuration fields
--------------------------
-
-- host-id
-
-This represents host identification string. This string will be stored in
-external_ids field with the key as odl_os_hostconfig_hostid.
-Refer to Neutron config definition for host field for details on this field.
-
-http://docs.openstack.org/kilo/config-reference/content/section_neutron.conf.html
-
-- host-type
-
-The field is for type of the node. This value corresponds to agent_type in
-agent_db. Example value are “ODL L2” and “ODL L3” for Compute and Network node
-respectively. Same host can be configured to have multiple configurations and
-can therefore can have both L2, L3 and other configurations at the same time.
-This string will be populated by ODL based on the configurations available
-on the host. See example in section below.
-
-- config
-
-This is the configuration data for the host type. Since same node can be
-configured to store multiple configurations different external_ids key value
-pair are used to store these configuration. The external_ids with keys as
-odl_os_hostconfig_config_odl_XXXXXXXX store different configurations.
-8 characters after the suffix odl_os_hostconfig_config_odl are host type.
-ODL extracts these characters and store that as the host-type fields. For
-example odl_os_hostconfig_config_odl_l2, odl_os_hostconfig_config_odl_l3 keys
-are used to provide L2 and L3 configurations respectively. ODL will extract
-"ODL L2" and "ODL L3" as host-type field from these keys and populate
-host-type field.
-
-Config is a Json string. Some examples of config:
-
-::
-
-    {“supported_vnic_types”: [{
-            “vnic_type”: “normal”,
-            “vif_type”: “ovs”,
-            “vif_details”: “{}”
-        }]
-        “allowed_network_types”: ["local", "gre", "vlan", "vxlan"]”,
-        “bridge_mappings”: {“physnet1":"br-ex”}
-   }"
-
-   {“supported_vnic_types”: [{
-            “vnic_type”: “normal”,
-            “vif_type”: “vhostuser”,
-            “vif_details”: “{“port_filter”: “False”, “vhostuser_socket”: “/var/run/openvswitch”}”
-        }]
-        “allowed_network_types”: ["local", "gre", "vlan", "vxlan"]”,
-        “bridge_mappings”: {“physnet1":"br-ex”}
-   }"
-
-**Host Config URL**
-
-Url : http://ip:odlport/restconf/operational/neutron:neutron/hostconfigs/
-
-**Commands to setup host config in OVSDB**
-::
-
- export OVSUUID=$(ovs-vsctl get Open_vSwitch . _uuid)
- ovs-vsctl set Open_vSwitch $OVSUUID external_ids:odl_os_hostconfig_hostid=test_host
- ovs-vsctl set Open_vSwitch $OVSUUID external_ids:odl_os_hostconfig_config_odl_l2 =
- "{“supported_vnic_types”: [{“vnic_type”: “normal”, “vif_type”: “ovs”, "vif_details": {} }], “allowed_network_types”: [“local”], “bridge_mappings”: {“physnet1":"br-ex”}}"
-
-Example for host configuration
--------------------------------
-
-::
-
-  {
-  "hostconfigs": {
-    "hostconfig": [
-      {
-        "host-id": "test_host1",
-        "host-type": "ODL L2",
-        "config":
-        "{“supported_vnic_types”: [{
-            “vnic_type”: “normal”,
-            “vif_type”: “ovs”,
-            “vif_details”: {}
-        }]
-        “allowed_network_types”: ["local", "gre", "vlan", "vxlan"],
-        “bridge_mappings”: {“physnet1":"br-ex”}}"
-      },
-      {
-        "host-id": "test_host2",
-        "host-type": "ODL L3",
-        "config": {}
-      }]
-    }
-  }
diff --git a/networking-odl/doc/source/devref/index.rst b/networking-odl/doc/source/devref/index.rst
deleted file mode 100644
index 1bf7790..0000000
--- a/networking-odl/doc/source/devref/index.rst
+++ /dev/null
@@ -1,36 +0,0 @@
-..
-      Licensed under the Apache License, Version 2.0 (the "License"); you may
-      not use this file except in compliance with the License. You may obtain
-      a copy of the License at
-
-          http://www.apache.org/licenses/LICENSE-2.0
-
-      Unless required by applicable law or agreed to in writing, software
-      distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
-      WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
-      License for the specific language governing permissions and limitations
-      under the License.
-
-
-Developer Guide
-===============
-
-In the Developer Guide, you will find information on networking-odl's lower
-level design and implementation details.
-
-
-Contents:
---------------------------------
-.. toctree::
-    :maxdepth: 2
-
-   hostconfig
-
-
-Indices and tables
-==================
-
-* :ref:`genindex`
-* :ref:`modindex`
-* :ref:`search`
-
diff --git a/networking-odl/doc/source/features.rst b/networking-odl/doc/source/features.rst
new file mode 100644
index 0000000..87e7027
--- /dev/null
+++ b/networking-odl/doc/source/features.rst
@@ -0,0 +1,9 @@
+========
+Features
+========
+
+.. toctree::
+   :maxdepth: 1
+
+   sfc-driver
+
diff --git a/networking-odl/doc/source/index.rst b/networking-odl/doc/source/index.rst
index 312dbe0..05cd1d5 100644
--- a/networking-odl/doc/source/index.rst
+++ b/networking-odl/doc/source/index.rst
@@ -15,16 +15,7 @@ Contents:
    installation
    usage
    contributing
-   specs
-
-Developer Docs
-==============
-
-.. toctree::
-   :maxdepth: 1
-
-   devref/index
-
+   features
 
 Indices and tables
 ==================
diff --git a/networking-odl/doc/source/sfc-driver.rst b/networking-odl/doc/source/sfc-driver.rst
new file mode 100644
index 0000000..a308656
--- /dev/null
+++ b/networking-odl/doc/source/sfc-driver.rst
@@ -0,0 +1,128 @@
+=================================================
+Service Function Chaining Driver for OpenDaylight
+=================================================
+
+This spec describes the plan to implement OpenStack networking-sfc[1] driver for OpenDaylight
+Controller.
+
+Problem Statement
+===================
+OpenStack SFC project (networking-sfc [1]) exposes generic APIs[2] for Service Function Chaining
+(SFC) that can be implemented by any backend networking service provider to support SFC. These APIs
+provide a way to integrate OpenStack SFC with any of the backend SFC providers. OpenDaylight SFC
+project provides a very mature implementation of SFC [3], but currently there is no formal
+integration mechanism present to consume OpenDaylight as an SFC provider for networking-sfc.
+
+Recently Tacker project [4] has been approved as an official project in OpenStack, that opens many
+possibilities to realize the NFV use cases (e.g SFC) using OpenStack as a platform. Providing a
+formal end to end integration between OpenStack and OpenDaylight for SFC use case will help NFV
+users leverage OpenStack, Tacker and OpenDaylight as a solution. A POC for this integration work has
+already been implemented [5][6] by Tim Rozet, but in this POC work, Tacker directly communicates
+to OpenDaylight SFC & classifier providers and not through OpenStack SFC APIs (networking-sfc).
+
+Proposed Change
+===============
+Implementation of this spec will introduce a networking-sfc[1] driver for OpenDaylight Controller in
+networking-odl project that will pass through the networking-sfc API's call to the OpenDaylight
+Controller.
+
+Detailed Design
+===============
+To enable the formal end to end integration between OpenStack SFC and OpenDaylight requires an
+SFC driver for OpenDaylight. ODL SFC driver will act as a shim layer between OpenStack and
+OpenDaylight that will carry out following two main tasks:
+
+* Translation of OpenStack SFC Classifier API to ODL SFC classifier yang models**
+
+* Translation of OpenStack SFC API's to OpenDaylight Neutron Northbound SFC models** [8]
+
+** This work is not yet done, but the OpenDaylight neutron northbound project needs to come up with
+yang models for SFC classification/chain. These models will be based on the existing networking-sfc
+APIs. This work is out of scope of networking-odl work and will be collaborated in the scope of the
+OpenDaylight Neutron Northbound project.
+
+SFC providers (E.g Net-Virt, GBP, SFC ) in OpenDaylight can listen to these OpenDaylight Neutron
+Northbound SFC models and translate it to their specific yang models for classification/sfc. The
+following diagram shows the high level integration between OpenStack and the OpenDaylight SFC
+provider::
+
+                            +---------------------------------------------+
+                            | OpenStack Network Server (networking-sfc)   |
+                            |            +-------------------+            |
+                            |            | networking-odl    |            |
+                            |            |   SFC Driver      |            |
+                            |            +-------------------+            |
+                            +----------------------|----------------------+
+                                                   | REST Communication
+                                                   |
+                                         -----------------------
+                OpenDaylight Controller |                       |
+                +-----------------------|-----------------------|---------------+
+                |            +----------v----+              +---v---+           |
+                | Neutron    | SFC Classifier|              |SFC    | Neutron   |
+                | Northbound |    Models     |              |Models | Northbound|
+                | Project    +---------------+              +-------+ Project   |
+                |               /        \                      |               |
+                |             /           \                     |               |
+                |           /               \                   |               |
+                |     +-----V--+        +---V----+          +---V---+           |
+                |     |Net-Virt|  ...   |   GBP  |          |  SFC  |  ...      |
+                |     +---------+       +--------+          +-------+           |
+                +-----------|----------------|------------------|---------------+
+                            |                |                  |
+                            |                |                  |
+                +-----------V----------------V------------------V---------------+
+                |                     Network/OVS                               |
+                |                                                               |
+                +---------------------------------------------------------------+
+
+In the above architecture, the opendaylight components are shown just to understand the overall
+architecture, but it's out of scope of this spec's work items. This spec will only track
+progress related to networking-odl OpenStack sfc driver work.
+
+Given that OpenStack SFC APIs are port-pair based API's and OpenDaylight SFC API's are based on
+IETF SFC yang models[8], there might be situations where translation might requires API enhancement
+from OpenStack SFC. Networking SFC team is open for these new enhancement requirements given that
+they are generic enough to be leveraged by other backend SFC providers[9]. This work will be
+leveraging the POC work done by Tim [10] to come up with the first version of SFC driver.
+
+Dependencies
+============
+It has a dependency on OpenDaylight Neutron Northbound SFC classifier and chain yang models, but
+that is out of scope of this spec.
+
+Impact
+======
+None
+
+Assignee(s)
+===========
+
+Following developers will be the initial contributor to the driver, but we will be happy to have
+more contributor on board.
+
+* Anil Vishnoi (vishnoianil@gmail.com, irc: vishnoianil)
+* Tim Rozet (trozet@redhat.com, irc: trozet)
+
+References
+==========
+
+[1] http://docs.openstack.org/developer/networking-sfc/
+
+[2] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
+
+[3] https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
+
+[4] https://wiki.openstack.org/wiki/Tacker
+
+[5] https://github.com/trozet/tacker/tree/SFC_brahmaputra/tacker/sfc
+
+[6] https://github.com/trozet/tacker/tree/SFC_brahmaputra/tacker/sfc_classifier
+
+[7] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-05
+
+[8] https://wiki.opendaylight.org/view/NeutronNorthbound:Main
+
+[9] http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-03-31-17.00.log.html
+
+[10] https://github.com/trozet/tacker/blob/SFC_brahmaputra/tacker/sfc/drivers/opendaylight.py
diff --git a/networking-odl/doc/source/specs.rst b/networking-odl/doc/source/specs.rst
deleted file mode 100644
index 6050296..0000000
--- a/networking-odl/doc/source/specs.rst
+++ /dev/null
@@ -1,26 +0,0 @@
-..
- This work is licensed under a Creative Commons Attribution 3.0 Unported
- License.
-
- http://creativecommons.org/licenses/by/3.0/legalcode
-
- neutron networking-odl specs documentation master file
-
-=============================================
-Neutron networking-odl Project Specifications
-=============================================
-
-Specs
-=====
-
-.. toctree::
-   :glob:
-   :maxdepth: 1
-
-   specs/*
-
-==================
-Indices and tables
-==================
-
-* :ref:`search`
diff --git a/networking-odl/doc/source/specs/journal-recovery.rst b/networking-odl/doc/source/specs/journal-recovery.rst
deleted file mode 100644
index 1132485..0000000
--- a/networking-odl/doc/source/specs/journal-recovery.rst
+++ /dev/null
@@ -1,152 +0,0 @@
-..
- This work is licensed under a Creative Commons Attribution 3.0 Unported
- License.
-
- http://creativecommons.org/licenses/by/3.0/legalcode
-
-================
-Journal Recovery
-================
-
-https://blueprints.launchpad.net/networking-odl/+spec/journal-recovery
-
-Journal entries in the failed state need to be handled somehow. This spec will
-try to address the issue and propose a solution.
-
-Problem Description
-===================
-
-Currently there is no handling for Journal entries that reach the failed state.
-A journal entry can reach the failed state for several reasons, some of which
-are:
-
-* Reached maximum failed attempts for retrying the operation.
-
-* Inconsistency between ODL and the Neutron DB.
-
-  * For example: An update fails because the resource doesn't exist in ODL.
-
-* Bugs that can lead to failure to sync up.
-
-These entries will be left in the journal table forever which is a bit wasteful
-since they take up some space on the DB storage and also affect the performance
-of the journal table.
-Albeit each entry has a negligble effect on it's own, the impact of a large
-number of such entries can become quite significant.
-
-Proposed Change
-===============
-
-A "journal recovery" routine will run as part of the current journal
-maintenance process.
-This routine will scan the journal table for rows in the "failed" state and
-will try to sync the resource for that entry.
-
-The procedure can be best described by the following flow chart:
-
-asciiflow::
-
-  +-----------------+
-  | For each entry  |
-  | in failed state |
-  +-------+---------+
-          |
-  +-------v--------+
-  | Query resource |
-  | on ODL (REST)  |
-  +-----+-----+----+
-        |     |                          +-----------+
-     Resource |                          | Determine |
-     exists   +--Resource doesn't exist--> operation |
-        |                                | type      |
-  +-----v-----+                          +-----+-----+
-  | Determine |                                |
-  | operation |                                |
-  | type      |                                |
-  +-----+-----+                                |
-        |              +------------+          |
-        +--Create------> Mark entry <--Delete--+
-        |              | completed  |          |
-        |              +----------^-+       Create/
-        |                         |         Update
-        |                         |            |
-        |          +------------+ |      +-----v-----+
-        +--Delete--> Mark entry | |      | Determine |
-        |          | pending    | |      | parent    |
-        |          +---------^--+ |      | relation  |
-        |                    |    |      +-----+-----+
-  +-----v------+             |    |            |
-  | Compare to +--Different--+    |            |
-  | resource   |                  |            |
-  | in DB      +--Same------------+            |
-  +------------+                               |
-                                               |
-  +-------------------+                        |
-  | Create entry for  <-----Has no parent------+
-  | resource creation |                        |
-  +--------^----------+                  Has a parent
-           |                                   |
-           |                         +---------v-----+
-           +------Parent exists------+ Query parent  |
-                                     | on ODL (REST) |
-                                     +---------+-----+
-  +------------------+                         |
-  | Create entry for <---Parent doesn't exist--+
-  | parent creation  |
-  +------------------+
-
-For every error during the process the entry will remain in failed state but
-the error shouldn't stop processing of further entries.
-
-
-The implementation could be done in two phases where the parent handling is
-done in a a second pahse.
-For the first phase if we detect an entry that is in failed for a create/update
-operation and the resource doesn't exist on ODL we create a new "create
-resource" journal entry for the resource.
-
-This propsal utilises the journal mechanism for it's operation while the only
-part that deviates from the standard mode of operation is when it queries ODL
-directly. This direct query has to be done to get ODL's representation of the
-resource.
-
-Performance Impact
-------------------
-
-The maintenance thread will have another task to handle. This can lead to
-longer processing time and even cause the thread to skip an iteration.
-This is not an issue since the maintenance thread runs in parallel and doesn't
-directly impact the responsiveness of the system.
-
-Since most operations here involve I/O then CPU probably won't be impacted.
-
-Network traffic would be impacted slightly since we will attempt to fetch the
-resource each time from ODL and we might attempt to fetch it's parent.
-This is however negligble as we do this only for failed entries, which are
-expected to appear rarely.
-
-
-Alternatives
-------------
-
-The partial sync process could make this process obsolete (along with full
-sync), but it's a far more complicated and problematic process.
-It's better to start with this process which is more lightweight and doable
-and consider partial sync in the future.
-
-
-Assignee(s)
-===========
-
-Primary assignee:
-  mkolesni <mkolesni@redhat.com>
-
-Other contributors:
-  None
-
-
-References
-==========
-
-https://goo.gl/IOMpzJ
-
diff --git a/networking-odl/doc/source/specs/qos-driver.rst b/networking-odl/doc/source/specs/qos-driver.rst
deleted file mode 100644
index d2faad1..0000000
--- a/networking-odl/doc/source/specs/qos-driver.rst
+++ /dev/null
@@ -1,104 +0,0 @@
-==========================================
-Quality of Service Driver for OpenDaylight
-==========================================
-
-This spec describes the plan to implement quality of service driver for
-OpenDaylight Controller.
-
-Problem Statement
-=================
-OpenStack networking project (neutron [1]) have a extension plugin implemented
-and which expose api for quality of service that can be also be implemented by
-any backend networking service provider to support QoS. These APIs provide a
-way to integrate OpenStack Neutron QoS with any of the backend QoS providers.
-OpenDaylight will provide backend for existing functionalities in neutron-QoS.
-A notification driver is needed for integration of existing api in Openstack
-neutron for QoS with OpenDaylight backend.
-
-Proposed Change
-===============
-This change will introduce a new notification driver in networking-odl that
-will take CRUD requests data for QoS policies from OpenStack neutron and notify
-the OpenDaylight controller about the respective operation.
-
-Detailed Design
-===============
-To enable the formal end to end integration between OpenStack QoS and
-OpenDaylight requires an networking-odl QoS notification driver. QoS driver
-will act as a shim layer between OpenStack and OpenDaylight that will carry
-out following task:
-
-#. After getting QoS policy request data from neutron, It will log a operation
-    request in opendaylightjournal table.
-
-#. The operation will be picked from opendaylightjournal table and a rest call
-    for notifying OpenDaylight server will be prepared and sent.
-
-#. This request will processed by neutron northbound in OpenDaylight.
-The OpenDaylight neutron northbound project. These models will be based
-on the existing neutron qos plugin APIs.
-
-QoS providers in OpenDaylight can listen to these OpenDaylight Neutron
-Northbound QoS models and translate it to their specific yang models for QoS.
-The following diagram shows the high level integration between OpenStack and
-the OpenDaylight QoS provider::
-
-                           +---------------------------------------------+
-                           | OpenStack Network Server (neutron qos)      |
-                           |                                             |
-                           |            +---------------------+          |
-                           |            | networking-odl      |          |
-                           |            |                     |          |
-                           |            |     +---------------|          |
-                           |            |     | Notification  |          |
-                           |            |     | driver QoS    |          |
-                           +----------------------|----------------------+
-                                                  |
-                                                  | Rest Communication
-                                                  |
-                    OpenDaylight Controller       |
-                          +-----------------------|------------+
-                          |            +----------V----+       |
-                          | ODL        | QoS Yang Model|       |
-                          | Northbound |               |       |
-                          | (neutron)  +---------------+       |
-                          |                    |               |
-                          |                    |               |
-                          | ODL           +----V----+          |
-                          | Southbound    | QoS     |          |
-                          | (neutron)     +---------+          |
-                          +-----------------|------------------+
-                                            |
-                                            |
-                          +------------------------------------+
-                          |           Network/OVS              |
-                          |                                    |
-                          +------------------------------------+
-
-In the above diagram, the OpenDaylight components are shown just to understand
-the overall architecture, but it's out of scope of this spec's work items.
-This spec will only track progress related to networking-odl notification QoS
-driver work.
-
-Dependencies
-============
-It has a dependency on OpenDaylight Neutron Northbound QoS yang models, but
-that is out of scope of this spec.
-
-Impact
-======
-None
-
-Assignee(s)
-===========
-
-Following developers will be the initial contributor to the driver, but we
-will be happy to have more contributor on board.
-
-* Manjeet Singh Bhatia (manjeet.s.bhatia@intel.com, irc: manjeets)
-
-References
-==========
-
-[1] http://docs.openstack.org/developer/neutron/devref/quality_of_service.html
-[2] https://wiki.opendaylight.org/view/NeutronNorthbound:Main
diff --git a/networking-odl/doc/source/specs/sfc-driver.rst b/networking-odl/doc/source/specs/sfc-driver.rst
deleted file mode 100644
index 388b2c1..0000000
--- a/networking-odl/doc/source/specs/sfc-driver.rst
+++ /dev/null
@@ -1,139 +0,0 @@
-=================================================
-Service Function Chaining Driver for OpenDaylight
-=================================================
-
-This spec describes the plan to implement OpenStack networking-sfc[1] driver
-for OpenDaylight Controller.
-
-Problem Statement
-===================
-OpenStack SFC project (networking-sfc [1]) exposes generic APIs[2] for Service
-Function Chaining (SFC) that can be implemented by any backend networking
-service provider to support SFC. These APIs provide a way to integrate
-OpenStack SFC with any of the backend SFC providers. OpenDaylight SFC project
-provides a very mature implementation of SFC [3], but currently there is no
-formal integration mechanism present to consume OpenDaylight as an SFC provider
-for networking-sfc.
-
-Recently Tacker project [4] has been approved as an official project in
-OpenStack, that opens many possibilities to realize the NFV use cases (e.g SFC)
-using OpenStack as a platform. Providing a formal end to end integration
-between OpenStack and OpenDaylight for SFC use case will help NFV users
-leverage OpenStack, Tacker and OpenDaylight as a solution. A POC for this
-integration work has already been implemented [5][6] by Tim Rozet, but in
-this POC work, Tacker directly communicates to OpenDaylight SFC & classifier
-providers and not through OpenStack SFC APIs (networking-sfc).
-
-Proposed Change
-===============
-Implementation of this spec will introduce a networking-sfc[1] driver for
-OpenDaylight Controller in networking-odl project that will pass through
-the networking-sfc API's call to the OpenDaylight Controller.
-
-Detailed Design
-===============
-To enable the formal end to end integration between OpenStack SFC and
-OpenDaylight requires an SFC driver for OpenDaylight. ODL SFC driver will
-act as a shim layer between OpenStack and OpenDaylight that will carry out
-following two main tasks:
-
-* Translation of OpenStack SFC Classifier API to ODL SFC classifier yang
-  models**.
-
-* Translation of OpenStack SFC API's to OpenDaylight Neutron Northbound
-  SFC models** [8].
-
-** This work is not yet done, but the OpenDaylight neutron northbound project
-needs to come up with yang models for SFC classification/chain. These models
-will be based on the existing networking-sfc APIs. This work is out of scope
-of networking-odl work and will be collaborated in the scope of OpenDaylight
-Neutron Northbound project.
-
-SFC providers (E.g Net-Virt, GBP, SFC ) in OpenDaylight can listen to these
-OpenDaylight Neutron Northbound SFC models and translate it to their specific
-yang models for classification/sfc. The following diagram shows the high level
-integration between OpenStack and the OpenDaylight SFC provider::
-
-                         +---------------------------------------------+
-                         | OpenStack Network Server (networking-sfc)   |
-                         |            +-------------------+            |
-                         |            | networking-odl    |            |
-                         |            |   SFC Driver      |            |
-                         |            +-------------------+            |
-                         +----------------------|----------------------+
-                                                | REST Communication
-                                                |
-                                      -----------------------
-             OpenDaylight Controller |                       |
-             +-----------------------|-----------------------|---------------+
-             |            +----------v----+              +---v---+           |
-             | Neutron    | SFC Classifier|              |SFC    | Neutron   |
-             | Northbound |    Models     |              |Models | Northbound|
-             | Project    +---------------+              +-------+ Project   |
-             |               /        \                      |               |
-             |             /           \                     |               |
-             |           /               \                   |               |
-             |     +-----V--+        +---V----+          +---V---+           |
-             |     |Net-Virt|  ...   |   GBP  |          |  SFC  |  ...      |
-             |     +---------+       +--------+          +-------+           |
-             +-----------|----------------|------------------|---------------+
-                         |                |                  |
-                         |                |                  |
-             +-----------V----------------V------------------V---------------+
-             |                     Network/OVS                               |
-             |                                                               |
-             +---------------------------------------------------------------+
-
-In the above architecture, the opendaylight components are shown just to
-understand the overall architecture, but it's out of scope of this spec's
-work items. This spec will only track progress related to networking-odl
-OpenStack sfc driver work.
-
-Given that OpenStack SFC APIs are port-pair based API's and OpenDaylight SFC
-API's are based on IETF SFC yang models[8], there might be situations where
-translation might requires API enhancement from OpenStack SFC. Networking SFC
-team is open for these new enhancement requirements given that they are generic
-enough to be leveraged by other backend SFC providers[9]. This work will be
-leveraging the POC work done by Tim [10] to come up with the first version of
-SFC driver.
-
-Dependencies
-============
-It has a dependency on OpenDaylight Neutron Northbound SFC classifier and chain
-yang models, but that is out of scope of this spec.
-
-Impact
-======
-None
-
-Assignee(s)
-===========
-
-Following developers will be the initial contributor to the driver, but we will
-be happy to have more contributor on board.
-
-* Anil Vishnoi (vishnoianil@gmail.com, irc: vishnoianil)
-* Tim Rozet (trozet@redhat.com, irc: trozet)
-
-References
-==========
-
-[1] http://docs.openstack.org/developer/networking-sfc/
-
-[2] https://github.com/openstack/networking-sfc/blob/master/doc/source/api.rst
-
-[3] https://wiki.opendaylight.org/view/Service_Function_Chaining:Main
-
-[4] https://wiki.openstack.org/wiki/Tacker
-
-[5] https://github.com/trozet/tacker/tree/SFC_brahmaputra/tacker/sfc
-
-[6] https://github.com/trozet/tacker/tree/SFC_brahmaputra/tacker/sfc_classifier
-
-[7] https://tools.ietf.org/html/draft-ietf-netmod-acl-model-05
-
-[8] https://wiki.opendaylight.org/view/NeutronNorthbound:Main
-
-[9] http://eavesdrop.openstack.org/meetings/service_chaining/2016/service_chaining.2016-03-31-17.00.log.html
-
-[10] https://github.com/trozet/tacker/blob/SFC_brahmaputra/tacker/sfc/drivers/opendaylight.py