summaryrefslogtreecommitdiffstats
path: root/networking-odl/doc/source
diff options
context:
space:
mode:
authorWojciech Dec <wdec@cisco.com>2016-08-17 13:14:23 +0200
committerWojciech Dec <wdec@cisco.com>2016-08-17 13:14:23 +0200
commit4979a23b8b2c0094ced98cf05eebb692d6609937 (patch)
treec49ceeb5b127fdb0e10c0f5ac0516be96cbd31a9 /networking-odl/doc/source
parentc3b2c2a9a22bac5cf17813c589444d3abebaa23b (diff)
Correcting networking-odl to mitaka/stable + app topology patch
Change-Id: Iddcd8dda2d49fcdd8e0f37a1d052a6fa8a24b035 Signed-off-by: Wojciech Dec <wdec@cisco.com>
Diffstat (limited to 'networking-odl/doc/source')
-rw-r--r--networking-odl/doc/source/devref/hostconfig.rst119
-rw-r--r--networking-odl/doc/source/devref/index.rst36
-rw-r--r--networking-odl/doc/source/features.rst9
-rw-r--r--networking-odl/doc/source/index.rst11
-rw-r--r--networking-odl/doc/source/sfc-driver.rst128
-rw-r--r--networking-odl/doc/source/specs.rst26
-rw-r--r--networking-odl/doc/source/specs/journal-recovery.rst152
-rw-r--r--networking-odl/doc/source/specs/qos-driver.rst104
-rw-r--r--networking-odl/doc/source/specs/sfc-driver.rst139
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