Update the docs/development directory

MS6 requires to have the docs directory structure ready and a preliminary
versio of the documents inside it.

- Moved requirements file to the requirements folder
- Removed the NSH workaround info as we don't need it anymore
- Added some new requirements

Change-Id: Icca89c738b1eb1865adff510ca2850c592c7a14a
Signed-off-by: Manuel Buil <mbuil@suse.com>

6 files changed, 21 insertions, 30 deletions

diff --git a/docs/development/design/architecture.rst b/docs/development/design/architecture.rst
index b190a18f..60183702 100644
--- a/docs/development/design/architecture.rst
+++ b/docs/development/design/architecture.rst
@@ -100,30 +100,3 @@ OPNFV SFC Network Topology
 The following image details the Network Topology used in OPNFV Danube SFC:
 
 .. image:: ./images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg
-
-
-OVS NSH patch workaround
-++++++++++++++++++++++++
-
-When using NSH with VXLAN tunnels, it is important that the VXLAN tunnel is
-terminated in the SF VM. This allows the SF to see the NSH header, allowing
-it to decrement the NSI and also to use the NSH metadata. When using VXLAN with
-OpenStack, the tunnels are not terminated in the VM, but in the "br-int" OVS
-bridge. There is work ongoing in the upstream OVS community to implemement NSH
-encapsulation. To get around the way OpenStack handles VXLAN tunnels, the OVS
-work will also include the ability to encapsulate/decapsulate VXLAN tunnels from
-OpenFlow rules, instead of relying on the Vtep ports. The ongoing upstream OVS
-work will not be finished by the time OPNFV Danube is released, so
-a work-around has been created. This work-around will use a private branch of
-OVS that has a preliminary version of NSH implemented.
-
-The following diagram illustrates how packets will be sent to an SF, when the
-SFF has processed the packet and wants to send it to the SF:
-
-.. image:: ./images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg
-
-The following diagram illustrates how packets will sent from an SF to an SFF,
-once the SF has processed a packet:
-
-.. image:: ./images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg
-
diff --git a/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg b/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg
deleted file mode 100644
index 1b542888..00000000
--- a/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg
+++ /dev/null
diff --git a/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg b/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg
deleted file mode 100644
index 11eaf87b..00000000
--- a/docs/development/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg
+++ /dev/null
diff --git a/docs/development/design/index.rst b/docs/development/design/index.rst
index 02777dfa..6bb30b7a 100644
--- a/docs/development/design/index.rst
+++ b/docs/development/design/index.rst
@@ -15,4 +15,3 @@ Service Function Chaining (SFC)
    definitions.rst
    usecases.rst
    architecture.rst
-   requirements.rst
diff --git a/docs/development/requirements/index.rst b/docs/development/requirements/index.rst
new file mode 100644
index 00000000..e74a05e7
--- /dev/null
+++ b/docs/development/requirements/index.rst
@@ -0,0 +1,14 @@
+.. _sfc-design:
+
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+
+*******************************
+Service Function Chaining (SFC)
+*******************************
+
+.. toctree::
+   :numbered:
+   :maxdepth: 2
+
+   requirements.rst
diff --git a/docs/development/design/requirements.rst b/docs/development/requirements/requirements.rst
index 6d35d946..e83a3e7e 100644
--- a/docs/development/design/requirements.rst
+++ b/docs/development/requirements/requirements.rst
@@ -16,7 +16,7 @@ in an OPNFV environment.
 Detailed Requirements
 +++++++++++++++++++++
 
-These are the Danube specific requirements:
+These are the Euphrates specific requirements:
 
 1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE.
 
@@ -29,12 +29,17 @@ These are the Danube specific requirements:
 5 ODL will be the OpenStack Neutron backend and will handle all networking
   on the compute nodes.
 
+6 Tacker will use the networking-sfc API to configure ODL
+
+7 ODL will use flow based tunnels to create the VXLAN-GPE tunnels
+
 Long Term Requirements
 ++++++++++++++++++++++
 
-These requirements are out of the scope of the Danube release.
+These requirements are out of the scope of the Euphrates release.
 
 1 Dynamic movement of SFs across multiple Compute nodes.
 
 2 Load Balancing across multiple SFs
 
+3 Support of a different MANO component apart from Tacker