5 files changed, 0 insertions, 68 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/design/requirements.rst b/docs/development/design/requirements.rst
deleted file mode 100644
index 6d35d946..00000000
--- a/docs/development/design/requirements.rst
+++ /dev/null
@@ -1,40 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Requirements
-------------
-
-This section defines requirements for the initial OPNFV SFC implementation,
-including those requirements driving upstream project enhancements.
-
-Minimal Viable Requirement
-++++++++++++++++++++++++++
-
-Deploy a complete SFC solution by integrating OpenDaylight SFC with OpenStack
-in an OPNFV environment.
-
-Detailed Requirements
-+++++++++++++++++++++
-
-These are the Danube specific requirements:
-
-1 The supported Service Chaining encapsulation will be NSH VXLAN-GPE.
-
-2 The version of OVS used must support NSH.
-
-3 The SF VM life cycle will be managed by the Tacker VNF Manager.
-
-4 The supported classifier is OpenDaylight NetVirt.
-
-5 ODL will be the OpenStack Neutron backend and will handle all networking
-  on the compute nodes.
-
-Long Term Requirements
-++++++++++++++++++++++
-
-These requirements are out of the scope of the Danube release.
-
-1 Dynamic movement of SFs across multiple Compute nodes.
-
-2 Load Balancing across multiple SFs
-