Migrate docs to the new Danube dir structure

Change-Id: I6bdfd21add4d04f0fee988f83888c1edcc488951
Signed-off-by: Brady Johnson <brady.allen.johnson@ericsson.com>

11 files changed, 0 insertions, 275 deletions

diff --git a/docs/design/architecture.rst b/docs/design/architecture.rst
deleted file mode 100644
index 679bb2f9..00000000
--- a/docs/design/architecture.rst
+++ /dev/null
@@ -1,129 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Architecture
-------------
-
-This section describes the architectural approach to incorporating the upstream
-OpenDaylight (ODL) SFC project into the OPNFV Colorado platform.
-
-Service Functions
-+++++++++++++++++
-
-A Service Function (SF) is a Function that provides services to flows traversing
-a Service Chain. Examples of typical SFs include: Firewall, NAT, QoS, and DPI.
-In the context of OPNFV, the SF will be a Virtual Network Function. The SFs
-receive data packets from a Service Function Forwarder.
-
-Service Function Forwarders
-+++++++++++++++++++++++++++
-
-The Service Function Forwarder (SFF) is the core element used in Service
-Chaining. It is an OpenFlow switch that, in the context of OPNFV, is hosted
-in an OVS bridge. In OPNFV there will be one SFF per Compute Node that will
-be hosted in the "br-int" OpenStack OVS bridge.
-
-The responsibility of the SFF is to steer incoming packets to the corresponding
-Service Function, or to the SFF in the next compute node. The flows in the SFF
-are programmed by the OpenDaylight SFC SDN Controller.
-
-Service Chains
-++++++++++++++
-
-Service Chains are defined in the OpenDaylight SFC Controller using the
-following constructs:
-
-SFC
-  A Service Function Chain (SFC) is an ordered list of abstract SF types.
-
-SFP
-  A Service Function Path (SFP) references an SFC, and optionally provides
-  concrete information about the SFC, like concrete SF instances. If SF
-  instances are not supplied, then the RSP will choose them.
-
-RSP
-  A Rendered Service Path (RSP) is the actual Service Chain. An RSP references
-  an SFP, and effectively merges the information from the SFP and SFC to create
-  the Service Chain. If concrete SF details were not provided in the SFP, then
-  SF selection algorithms are used to choose one. When the RSP is created, the
-  OpenFlows will be programmed and written to the SFF(s).
-
-Service Chaining Encapsulation
-++++++++++++++++++++++++++++++
-
-Service Chaining Encapsulation encapsulates traffic sent through the Service
-Chaining domain to facilitate easier steering of packets through Service Chains.
-If no Service Chaining Encapsulation is used, then packets much be classified
-at every hop of the chain, which would be slow and would not scale well.
-
-In ODL SFC, Network Service Headers (NSH) is used for Service Chaining
-encapsulation. NSH is an IETF specification that uses 2 main header
-fields to facilitate packet steering, namely:
-
-NSP (NSH Path)
-  The NSP is the Service Path ID.
-
-NSI (NSH Index)
-  The NSI is the Hop in the Service Chain. The NSI starts at 255 and is
-  decremented by every SF. If the NSI reaches 0, then the packet is dropped
-  which avoids loop detections.
-
-NSH also has metadata fields, but that's beyond the scope of this architecture.
-
-In ODL SFC, NSH packets are encapsulated in VXLAN-GPE.
-
-Classifiers
-+++++++++++
-
-A classifier is the entry point into Service Chaining. The role of the
-classifier is to map incoming traffic to Service Chains. In ODL SFC, this
-mapping is performed by matching the packets and encapsulating the packets in
-a VXLAN-GPE NSH tunnel.
-
-The packet matching is specific to the classifier implementation, but can be
-as simple as an ACL, or can be more complex by using PCRF information or DPI.
-
-VNF Manager
-+++++++++++
-
-In OPNFV SFC, a VNF Manager is needed to spin-up VMs for Service Functions.
-It has been decided to use the OpenStack Tacker VNF Mgr to spin-up and manage
-the life cylcle of the SFs. Tacker will receive the ODL SFC configuration,
-manage the SF VMs, and forward the configuration to ODL SFC. The following
-sequence diagram details the interactions with the VNF Mgr:
-
-.. image:: ./images/OPNFV_SFC_Brahmaputra_SfCreation.jpg
-
-OPNFV SFC Network Topology
-++++++++++++++++++++++++++
-
-The following image details the Network Topology used in OPNFV Colorado SFC:
-
-.. image:: ./images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg
-
-
-OVS NSH patch workaround
-++++++++++++++++++++++++
-
-When using NSH with VXLAN tunnels, its 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 Colorado 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/design/definitions.rst b/docs/design/definitions.rst
deleted file mode 100644
index 85416fb8..00000000
--- a/docs/design/definitions.rst
+++ /dev/null
@@ -1,64 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Definitions
------------
-
-Definitions of most terms used here are provided in the `IETF SFC Architecture RFC <https://datatracker.ietf.org/doc/rfc7665/>`_.
-Additional terms specific to the OPNFV SFC project are defined below.
-
-
-Abbreviations
--------------
-
-.. list-table:: Abbreviations
-   :widths: 15 85
-   :header-rows: 1
-
-   * - Abbreviation
-     - Term
-
-   * - NS
-     - Network Service
-
-   * - NFVO
-     - Network Function Virtualization Orchestrator
-
-   * - NF
-     - Network Function
-
-   * - NSH
-     - Network Services Header (Service chaining encapsulation)
-
-   * - ODL
-     - OpenDaylight SDN Controller
-
-   * - RSP
-     - Rendered Service Path
-
-   * - SDN
-     - Software Defined Networking
-
-   * - SF
-     - Service Function
-
-   * - SFC
-     - Service Function Chain(ing)
-
-   * - SFF
-     - Service Function Forwarder
-
-   * - SFP
-     - Service Function Path
-
-   * - VNF
-     - Virtual Network Function
-
-   * - VNFM
-     - Virtual Network Function Manager
-
-   * - VNF-FG
-     - Virtual Network Function Forwarding Graph
-
-   * - VIM
-     - Virtual Infrastructure Manager
diff --git a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg b/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg
deleted file mode 100644
index 1b542888..00000000
--- a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_fromSf.jpg
+++ /dev/null
diff --git a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg b/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg
deleted file mode 100644
index 11eaf87b..00000000
--- a/docs/design/images/OPNFV_SFC_BrahmaputraOvsNshWorkaround_toSf.jpg
+++ /dev/null
diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg
deleted file mode 100644
index c183486e..00000000
--- a/docs/design/images/OPNFV_SFC_Brahmaputra_NW_Topology.jpg
+++ /dev/null
diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg
deleted file mode 100644
index 345317dd..00000000
--- a/docs/design/images/OPNFV_SFC_Brahmaputra_SfCreation.jpg
+++ /dev/null
diff --git a/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg b/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg
deleted file mode 100644
index efc0df33..00000000
--- a/docs/design/images/OPNFV_SFC_Brahmaputra_UseCase.jpg
+++ /dev/null
diff --git a/docs/design/index.rst b/docs/design/index.rst
deleted file mode 100644
index f13d575b..00000000
--- a/docs/design/index.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. 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
-
-   introduction.rst
-   definitions.rst
-   usecases.rst
-   architecture.rst
-   requirements.rst
diff --git a/docs/design/introduction.rst b/docs/design/introduction.rst
deleted file mode 100644
index f7b7df76..00000000
--- a/docs/design/introduction.rst
+++ /dev/null
@@ -1,10 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Introduction
-------------
-
-The `OPNFV Service Function Chaining (SFC) <https://wiki.opnfv.org/display/sfc/Service+Function+Chaining+Home>`_
-project aims to provide the ability to define an ordered list of a network services (e.g. firewalls, NAT, QoS).
-These service are then "stitched" together in the network to create a service chain.
-This project provides the infrastructure to install the upstream ODL SFC implementation project in an NFV environment.
diff --git a/docs/design/requirements.rst b/docs/design/requirements.rst
deleted file mode 100644
index 1c15a9b9..00000000
--- a/docs/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 Colorado 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 Mgr.
-
-4 The supported classifiers will be either ODL Netvirt or ODL GBP.
-
-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 Colorado release.
-
-1 Dynamic movement of SFs across multiple Compute nodes.
-
-2 Load Balancing across multiple SFs
-
diff --git a/docs/design/usecases.rst b/docs/design/usecases.rst
deleted file mode 100644
index 23e94417..00000000
--- a/docs/design/usecases.rst
+++ /dev/null
@@ -1,16 +0,0 @@
-.. This work is licensed under a Creative Commons Attribution 4.0 International License.
-.. http://creativecommons.org/licenses/by/4.0
-
-Use Cases
----------
-
-This section outlines the Colorado use cases driving the initial OPNFV
-SFC implementation.
-
-The use cases targeted in the OPNFV SFC Colorado release focus on creating
-simple Service Chains using Firewall Service Functions. As can be seen in the
-following diagram, 2 service chains are created, each through a different
-Service Function Firewall. Service Chain 1 will block HTTP, while Service
-Chain 2 will block SSH.
-
-.. image:: ./images/OPNFV_SFC_Brahmaputra_UseCase.jpg