diff --git a/.gitignore b/.gitignore
index 8ed6db6..c0fb2d1 100644
--- a/.gitignore
+++ b/.gitignore
@@ -1,5 +1,6 @@
 # build related
 venv_docs
+doc_venv
 _build
 repos
 
@@ -11,6 +12,7 @@
 voltha-go
 voltha-openolt-adapter
 voltha-openonu-adapter
+voltha-openonu-adapter-go
 kind-voltha
 voltha-protos
 voltha-system-tests
@@ -19,3 +21,6 @@
 
 # IDEs
 .idea
+
+# OS
+.DS_Store
diff --git a/Makefile b/Makefile
index e674052..25ca56e 100644
--- a/Makefile
+++ b/Makefile
@@ -11,7 +11,7 @@
 
 # Other repos with documentation to include.
 # edit the `git_refs` file with the commit/tag/branch that you want to use
-OTHER_REPO_DOCS ?= bbsim cord-tester ofagent-go openolt voltctl voltha-openolt-adapter voltha-openonu-adapter voltha-protos voltha-system-tests kind-voltha
+OTHER_REPO_DOCS ?= bbsim cord-tester ofagent-go openolt voltctl voltha-openolt-adapter voltha-openonu-adapter voltha-openonu-adapter-go voltha-protos voltha-system-tests kind-voltha
 
 # Static docs, built by other means (usually robot framework)
 STATIC_DOCS    := _static/voltha-system-tests _static/cord-tester
diff --git a/_static/voltha_cluster_overview.png b/_static/voltha_cluster_overview.png
new file mode 100644
index 0000000..9ba8a0b
--- /dev/null
+++ b/_static/voltha_cluster_overview.png
Binary files differ
diff --git a/_static/voltha_cluster_virtual.png b/_static/voltha_cluster_virtual.png
new file mode 100644
index 0000000..b31707f
--- /dev/null
+++ b/_static/voltha_cluster_virtual.png
Binary files differ
diff --git a/conf.py b/conf.py
index 2e6b04d..4be53dd 100644
--- a/conf.py
+++ b/conf.py
@@ -62,6 +62,7 @@
     'sphinxcontrib.seqdiag',
     'sphinxcontrib.spelling',
     "sphinx_multiversion",
+    "sphinx.ext.intersphinx",
 #    'sphinxcontrib.golangdomain',
 #    'autoapi.extension',
 ]
@@ -117,6 +118,7 @@
 # This pattern also affects html_static_path and html_extra_path.
 exclude_patterns = [
         '*/LICENSE.md',
+        '*/RELEASE_NOTES.md',
         '*/vendor',
         '.DS_Store',
         'Thumbs.db',
@@ -135,6 +137,7 @@
         'bbsim/README.md',
         'CODE_OF_CONDUCT.md',
         '*/CODE_OF_CONDUCT.md',
+        'doc_venv/*'
 ]
 
 # The name of the Pygments (syntax highlighting) style to use.
diff --git a/git_refs b/git_refs
index 1fa3f0a..f81e56e 100644
--- a/git_refs
+++ b/git_refs
@@ -11,15 +11,16 @@
 
 _REPO NAME_             _DIR_    _REF_
 
-bbsim                   /        master
-cord-tester             /        master
-ofagent-go              /        master
-openolt                 /        master
-pyvoltha                /        master
-voltctl                 /        master
-voltha-go               /        master
-voltha-openolt-adapter  /        master
-voltha-openonu-adapter  /        master
-voltha-protos           /        master
-voltha-system-tests     /        master
-kind-voltha             /        master
+bbsim                      /        master
+cord-tester                /        master
+ofagent-go                 /        master
+openolt                    /        master
+pyvoltha                   /        master
+voltctl                    /        master
+voltha-go                  /        master
+voltha-openolt-adapter     /        master
+voltha-openonu-adapter     /        master
+voltha-openonu-adapter-go  /        master
+voltha-protos              /        master
+voltha-system-tests        /        master
+kind-voltha                /        master
diff --git a/index.rst b/index.rst
index c1c9d01..4817d9c 100644
--- a/index.rst
+++ b/index.rst
@@ -33,6 +33,12 @@
 
    VOLTHA Component Diagram
 
+Here some quick links to get you started:
+
+- :doc:`./overview/deployment_environment`
+- :doc:`./overview/workflows`
+- :doc:`./overview/quickstart`
+- :doc:`./overview/troubleshooting`
 
 Community
 ---------
@@ -48,9 +54,12 @@
    :hidden:
    :glob:
 
-   overview/*
+   overview/deployment_environment.rst
+   overview/workflows.rst
+   overview/quickstart.rst
+   overview/operate.rst
+   overview/troubleshooting.rst
    readme
-   VOLTHA Deployment Tool (kind-voltha) <kind-voltha/README.md>
 
 .. toctree::
    :maxdepth: 1
@@ -60,9 +69,12 @@
    BBSIM <bbsim/docs/source/index.rst>
    OpenFlow Agent <ofagent-go/README.md>
    OpenOlt Adapter <voltha-openolt-adapter/README.md>
+   OpenOnu Adapter <voltha-openonu-adapter/README.md>
+   OpenOnu Adapter Go <voltha-openonu-adapter-go/README.md>
    Openolt Agent <openolt/README.md>
    VOLTHA CLI <voltctl/README.md>
    VOLTHA Protos <voltha-protos/README.md>
+   Kind-voltha <kind-voltha/README.md>
 
 .. toctree::
    :maxdepth: 1
diff --git a/overview/deployment_environment.rst b/overview/deployment_environment.rst
new file mode 100644
index 0000000..44f877f
--- /dev/null
+++ b/overview/deployment_environment.rst
@@ -0,0 +1,68 @@
+VOLTHA Deployment Environment
+=============================
+
+All the components in the VOLTHA project are containerized and the default
+deployment environment is ``kubernetes``.
+
+Generally VOLTHA is installed in one of two setups:
+
+- A physical ``kubernetes`` cluster, generally used for production deployments.
+- A virtual ``kind`` cluster, generally used for development.
+
+Regardless of the chosen environment the deployment process is the same,
+more on this later, and the installation can be managed in the same way.
+
+Managing a VOLTHA deployment
+----------------------------
+
+VOLTHA components on top of ``kubernetes`` are managed via ``helm`` charts.
+For more information about ``helm`` please refer to the `Official Documentation
+<https://helm.sh>`_.
+For the sake of this guide all you need to know is that an
+``helm`` chart describes all the information required to deploy a component on top of
+``kubernetes``, such as: containers, exposed ports and configuration parameters.
+
+A VOLTHA deployment is composed, at its very minimum, by:
+
+* Infrastructure
+
+   * A ``kafka`` cluster (can also be a single node)
+   * An ``etcd`` cluster (can also be a single node)
+   * ``ONOS`` (single or multi instance)
+   * [Optional] ``radius`` (for EAPOL based authentication)
+* ``VOLTHA``
+
+   * ``voltha-core`` and ``ofAgent`` (contained in the same ``helm`` chart)
+* Adapters
+
+   * [one or more] adapter pair(s) (OLT adapter + ONU Adapter)
+
+.. figure:: ../_static/voltha_cluster_overview.png
+   :alt: VOLTHA Component Diagram
+   :width: 100%
+
+   VOLTHA Kubernetes deployment
+
+Note that the ``Infrastructure`` components can be deployed outside of the
+``kubernetes`` cluster.
+
+You can read more about VOLTHA deployments in:
+
+- :doc:`lab_setup`
+- :doc:`pod_physical`
+- :doc:`dev_virtual`
+
+.. toctree::
+   :maxdepth: 1
+   :hidden:
+   :glob:
+
+   ./lab_setup.rst
+   ./pod_physical.rst
+   ./dev_virtual.rst
+
+Tooling
+-------
+
+To simplify the installation of VOLTHA we provided a tool called ``kind-voltha``.
+You can read more on :doc:`kind-voltha <../kind-voltha/README>` in its own documentation.
diff --git a/overview/dev_virtual.rst b/overview/dev_virtual.rst
index 22f17db..586b160 100644
--- a/overview/dev_virtual.rst
+++ b/overview/dev_virtual.rst
@@ -3,11 +3,31 @@
 Developing code with a virtual VOLTHA POD
 =========================================
 
-A guide to install a virtual POD. This is generally used to gain familiarity with the
-environment or for development purposes.
+A guide to install a virtual POD. A virtual pod is generally used to gain familiarity with the
+environment or for development and testing purposes.
 
-Most of the `helm` and `voltctl` commands found in the :ref:`pod_physical` also
-apply in the virtual environment.
+How is it different from a Physical deployment?
+-----------------------------------------------
+
+The main difference is in the ``kubernetes`` cluster itself.
+In a Physical deployment we assume that the ``kubernetes`` cluster is installed
+on 3 (or mode) physical nodes.
+When installing a ``virtual`` cluster we refer to a ``kind`` (``kubernetes-in-docker``)
+cluster.
+
+Another common difference is that a Physical deployment is generally associated
+with one or more physical OLTs while a Virtual deployment normally emulates the
+PON network using :doc:`BBSim <../bbsim/docs/source/index>`.
+
+.. figure:: ../_static/voltha_cluster_virtual.png
+   :alt: VOLTHA Component Diagram
+   :width: 100%
+
+   VOLTHA Kubernetes kind deployment
+
+Note that is anyway possible to connect a physical OLT to a virtual cluster, as
+long as the OLT is reachable from the ``kind`` host machine. If you need to control
+your OLT "in-band" then it's not advised to connect it to a virtual cluster.
 
 Quickstart
 ----------
@@ -20,57 +40,9 @@
 
 .. code:: bash
 
-    TYPE=minimal WITH_RADIUS=y CONFIG_SADIS=y ONLY_ONE=y WITH_BBSIM=y ./voltha up
+    TYPE=minimal WITH_RADIUS=y CONFIG_SADIS=y WITH_BBSIM=y ./voltha up
 
-For more information you can visit the `kind-voltha page <kind-voltha/README.md>`_.
-
-Install BBSIM (Broad Band OLT/ONU Simulator)
---------------------------------------------
-
-BBSIM provides a simulation of a BB device. It can be useful for
-testing.
-
-Create BBSIM Device
-^^^^^^^^^^^^^^^^^^^
-
-After having deployed BBSIM either through `kind-voltha` or manually `bbsim <bbsim/docs/source/index.rst>`_ you can create a similated OLT.
-
-.. code:: bash
-
-   voltctl device create -t openolt -H $(kubectl get -n voltha service/bbsim -o go-template='{{.spec.clusterIP}}'):50060
-
-Enable BBSIM Device
-^^^^^^^^^^^^^^^^^^^
-
-.. code:: bash
-
-   voltctl device enable $(voltctl device list --filter Type~openolt -q)
-
-Observing the newly created device in ONOS
-------------------------------------------
-
-At this point you should be able to see a new device in ONOS.
-
-You can SSH into ONOS via
-
-.. code:: bash
-
-    ssh -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -p 8201 karaf@localhost
-
-with password ``karaf``.
-
-Now when issuing `ports` command you should see something along the lines of:
-
-.. code:: bash
-
-   karaf@root > ports
-   id=of:00000a0a0a0a0a00, available=true, local-status=connected 29s ago, role=MASTER, type=SWITCH, mfr=VOLTHA Project, hw=open_pon, sw=open_pon, serial=BBSIM_OLT_0, chassis=a0a0a0a0a00, driver=voltha, channelId=10.244.2.7:48630, managementAddress=10.244.2.7, protocol=OF_13
-   port=16, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:10, portName=BBSM00000001-1
-   port=17, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:11, portName=BBSM00000001-2
-   port=18, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:12, portName=BBSM00000001-3
-   port=19, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:13, portName=BBSM00000001-4
-   port=1048576, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=0a:0a:0a:0a:0a:00, portName=nni-1048576
-
+For more information you can visit the :doc:`kind-voltha page <../kind-voltha/README>`.
 
 Developing changes on a virtual pod
 -----------------------------------
@@ -121,42 +93,3 @@
 .. code:: bash
 
     $ DEPLOY_K8S=no ./voltha down && DEPLOY_K8S=no EXTRA_HELM_FLAGS="-f dev-values.yaml" ./voltha up
-
-Create Kubernetes Cluster
--------------------------
-
-Kind provides a command line control tool to easily create Kubernetes
-clusters using just a basic Docker environment. The following commands
-will create the desired deployment of Kubernetes and then configure your
-local copy of ``kubectl`` to connect to this cluster.
-
-.. code:: bash
-
-   kind create cluster --name=voltha-$TYPE --config $TYPE-cluster.cfg
-   export KUBECONFIG="$(kind get kubeconfig-path --name="voltha-$TYPE")"
-   kubectl cluster-info
-
-Initialize Helm
----------------
-
-Helm provide a capability to install and manage Kubernetes applications.
-VOLTHA’s default deployment mechanism utilized Helm. Before Helm can be
-used to deploy VOLTHA it must be initialized and the repositories that
-container the artifacts required to deploy VOLTHA must be added to Helm.
-
-.. code:: bash
-
-   # Initialize Helm and add the required chart repositories
-   helm init
-   helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com
-   helm repo add stable https://kubernetes-charts.storage.googleapis.com
-   helm repo add onf https://charts.opencord.org
-   helm repo update
-
-   # Create and k8s service account so that Helm can create pods
-   kubectl create serviceaccount --namespace kube-system tiller
-   kubectl create clusterrolebinding tiller-cluster-rule --clusterrole=cluster-admin --serviceaccount=kube-system:tiller
-   kubectl patch deploy --namespace kube-system tiller-deploy -p '{"spec":{"template":{"spec":{"serviceAccount":"tiller"}}}}'
-
-From this point follow the :ref:`physical VOLTHA POD installation instructions
-<installation_steps>`. Come back here once done.
diff --git a/overview/lab_setup.rst b/overview/lab_setup.rst
index 2659b0d..d0fb41b 100644
--- a/overview/lab_setup.rst
+++ b/overview/lab_setup.rst
@@ -19,7 +19,8 @@
    VOLTHA Lab Setup
 
 *The image above represents the data plane connections in a LAB setup.
-It does not include the kubernetes cluster for simplicity.*
+It does not include the ``kubernetes`` cluster for simplicity, but the ``dev server``
+listed above can be one of your ``kubernetes`` nodes.*
 
 What you’ll need to emulate E2E traffic is:
 
@@ -28,6 +29,8 @@
   - 1 1G Ethernet port
   - 1 10G Ethernet port (this can be a second 1G interface as long as you have a media converter)
 
+.. _setting-up-a-client:
+
 Setting up a client
 -------------------
 
diff --git a/overview/operate.rst b/overview/operate.rst
new file mode 100644
index 0000000..f43d19e
--- /dev/null
+++ b/overview/operate.rst
@@ -0,0 +1,154 @@
+.. _operate:
+
+Operate a VOLTHA POD
+====================
+
+In this page we assume that you have a VOLTHA POD (either Physical or Virtual) up and running.
+
+Provision an OLT
+----------------
+
+The first step in order to operate a VOLTHA POD is to add an OLT to it.
+
+If you deployed a Virtual cluster you can create a BBSim based OLT in VOLTHA with:
+
+.. code:: bash
+
+    voltctl device create -t openolt -H bbsim0.voltha.svc:50060
+
+*If you have deployed multiple BBSim instances using the ``NUM_OF_BBSIM`` variable
+you can list all the available BBSim OLTs with ``kubectl get svc --all-namespaces | grep bbsim``*
+
+If you are connecting to a Physical OLT:
+
+.. code:: bash
+
+    voltctl device create -t openolt -H <olt-management-ip>:9191
+
+Regardless of the OLT the command to ``enable`` an OLT in VOLTHA is always the same:
+
+.. code:: bash
+
+    voltctl device enable <device-id>
+
+*The ``device id`` is the output of the ``device create`` command, or can be retrieved
+with ``voltctl device list``*
+
+If you have just one OLT create you can use :
+
+.. code:: bash
+
+    voltctl device enable $(voltctl device list --filter Type~openolt -q)
+
+Once the OLT is ``enabled`` in VOLTHA you should be able to see the ONU attached
+to it by listing the devices:
+
+.. code:: bash
+
+    voltctl device list
+
+Authentication
+--------------
+
+If the use-case you installed (e.g. AT&T) expects EAPOL based authentication you want to make
+sure that is working. Visit :ref:`workflows` for more information.
+
+In a **Physical POD** you need to trigger authentication on your client
+(if it doesn't do so automatically). You can refer to :ref:`setting-up-a-client`.
+
+In a **Virtual POD** installed with the ``WITH_EAPOL="yes"`` flag authentication
+happens automatically.
+
+You can check the authentication state for your subscribers via the ONOS cli:
+
+.. code:: bash
+
+    ssh -p 8101 karaf@localhost # (pwd: karaf)
+    karaf@root > aaa-users
+    of:00000a0a0a0a0a00/16: AUTHORIZED_STATE, last-changed=5m14s ago, mac=2E:60:70:00:00:01, subid=BBSM00000001-1, username=user
+
+*Note that if ONOS was not installed as parted of VOLTHA the ``ssh`` command may differ*
+
+Subscriber provisioning
+-----------------------
+
+*Note that, depending on the workflow, authentication is not a requirement of subscriber provisioning*
+
+The process referred to as ``Subscriber provisioning`` causes traffic flows to be created in ONOS and
+ data plane path to be configured in the device, enabling different services on a specific UNI port.
+
+In order to provision a subscriber you need to identify it. In ONOS a subscriber
+is viewed as an enabled port (UNI) on the logical switch that VOLTHA exposes, for example:
+
+.. code:: bash
+
+    ssh -p 8101 karaf@localhost # (pwd: karaf)
+    karaf@root > ports -e
+    id=of:00000a0a0a0a0a00, available=true, local-status=connected 8m27s ago, role=MASTER, type=SWITCH, mfr=VOLTHA Project, hw=open_pon, sw=open_pon, serial=BBSIM_OLT_0, chassis=a0a0a0a0a00, driver=voltha, channelId=10.244.2.7:53576, managementAddress=10.244.2.7, protocol=OF_13
+      port=16, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:10, portName=BBSM00000001-1
+      port=1048576, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=0a:0a:0a:0a:0a:00, portName=nni-1048576
+
+Once the port number representing a subscriber has been retrieved, you can provision it via:
+
+.. code:: bash
+
+    ssh -p 8101 karaf@localhost # (pwd: karaf)
+    karaf@root > volt-add-subscriber-access of:00000a0a0a0a0a00 16
+
+Where ``of:00000a0a0a0a0a00`` is the OpenFlow ID of the Logical Device representing the OLT
+and ``16`` is the port representing that particular subscriber.
+
+To verify that the subscriber has been provisioned:
+
+.. code:: bash
+
+    ssh -p 8101 karaf@localhost # (pwd: karaf)
+    karaf@root > volt-programmed-subscribers
+    location=of:00000a0a0a0a0a00/16 tagInformation=UniTagInformation{uniTagMatch=0, ponCTag=900, ponSTag=900, usPonCTagPriority=-1, usPonSTagPriority=-1, dsPonCTagPriority=-1, dsPonSTagPriority=-1, technologyProfileId=64, enableMacLearning=false, upstreamBandwidthProfile='Default', downstreamBandwidthProfile='Default', serviceName='', configuredMacAddress='A4:23:05:00:00:00', isDhcpRequired=true, isIgmpRequired=false}
+
+You can also verify that the expected flows have been created and ``ADDED`` to VOLTHA:
+
+.. code:: bash
+
+    ssh -p 8101 karaf@localhost # (pwd: karaf)
+    karaf@root > flows -s
+    deviceId=of:00000a0a0a0a0a00, flowRuleCount=8
+      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16, ETH_TYPE:eapol, VLAN_VID:900], treatment=[immediate=[OUTPUT:CONTROLLER], meter=METER:1, metadata=METADATA:384004000000000/0]
+      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:16, ETH_TYPE:ipv4, VLAN_VID:900, IP_PROTO:17, UDP_SRC:68, UDP_DST:67], treatment=[immediate=[OUTPUT:CONTROLLER], meter=METER:1, metadata=METADATA:4000000000/0]
+      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:1048576, ETH_TYPE:lldp], treatment=[immediate=[OUTPUT:CONTROLLER]]
+      ADDED, bytes=0, packets=0, table=0, priority=10000, selector=[IN_PORT:1048576, ETH_TYPE:ipv4, IP_PROTO:17, UDP_SRC:67, UDP_DST:68], treatment=[immediate=[OUTPUT:CONTROLLER]]
+      ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:16, VLAN_VID:0], treatment=[immediate=[VLAN_ID:900], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004000100000/0]
+      ADDED, bytes=0, packets=0, table=0, priority=1000, selector=[IN_PORT:1048576, METADATA:384, VLAN_VID:900], treatment=[immediate=[VLAN_POP], transition=TABLE:1, meter=METER:1, metadata=METADATA:384004000000010/0]
+      ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:1048576, METADATA:10, VLAN_VID:900], treatment=[immediate=[VLAN_ID:0, OUTPUT:16], meter=METER:1, metadata=METADATA:4000000000/0]
+      ADDED, bytes=0, packets=0, table=1, priority=1000, selector=[IN_PORT:16, VLAN_VID:900], treatment=[immediate=[VLAN_PUSH:vlan, VLAN_ID:900, OUTPUT:1048576], meter=METER:1, metadata=METADATA:4000000000/0]
+
+*The flows above may vary in form and number from workflow to workflow, the example is given for the ATT workflow*
+
+DHCP Allocation
+---------------
+
+If the use-case you installed expect DHCP to be handled by ONOS it's time to check
+that an IP has correctly been allocated to the subscriber.
+
+In a **Physical POD** you need to trigger a DHCP request on your client
+(if it doesn't do so automatically). You can refer to :ref:`setting-up-a-client`.
+
+In a **Virtual POD** installed with the ``WITH_DHCP="yes"`` flag a DHCP requests
+happens automatically.
+
+You can check the DHCP state for your subscribers via the ONOS cli:
+
+.. code:: bash
+
+    ssh -p 8101 karaf@localhost # (pwd: karaf)
+    karaf@root > dhcpl2relay-allocations
+    01SubscriberId=BBSM00000001-1,ConnectPoint=of:00000a0a0a0a0a00/16,State=DHCPACK,MAC=2E:60:70:00:00:01,CircuitId=BBSM00000001-1,IP Allocated=192.168.240.6,Allocation Timestamp=2020-07-27T22:39:24.140361Z
+
+Data plane validation
+---------------------
+
+If you deployed a **Virtual POD** with a BBSim OLT you are done. BBSim does not support
+data plane emulation at the moment.
+
+If you deployed a **Physical POD** then you should now be able to reach the internet, from
+your client attached to the UNI port you provisioned during the ``subscriber provisioning`` step.
diff --git a/overview/pod_physical.rst b/overview/pod_physical.rst
index 8a35abe..91be3a6 100644
--- a/overview/pod_physical.rst
+++ b/overview/pod_physical.rst
@@ -3,10 +3,7 @@
 Deploy a physical VOLTHA POD
 ============================
 
-Quickstart
-----------
-
-The quickstart assumes you POD is already correctly cabled, if not you can
+This document assumes you POD is already correctly cabled, if not you can
 refer to :ref:`lab_setup`
 
 Requires:
@@ -21,262 +18,39 @@
 
 .. code:: bash
 
-    DEPLOY_K8S=no WITH_RADIUS=y CONFIG_SADIS=y ./voltha up
+    DEPLOY_K8S=no WITH_RADIUS=y CONFIG_SADIS=y SADIS_CFG="my-sadis-cfg.json" ./voltha up
+
+*``my-sadis-cfg.json`` is a reference to your own ``sadis`` configuration.
+This is needed to specify the appropriate values for your devices and subsribers*
 
 If you already have a ``radius`` server that you want to use, change the flag to ``WITH_RADIUS=n``
 and `configure ONOS accordingly <https://github.com/opencord/aaa>`_.
 
-For more information please check `kind-voltha page <kind-voltha/README.md>`_.
+For more information please check :doc:`kind-voltha page <../kind-voltha/README>`.
 
-TLDR;
------
+After the deployment please refer to :ref:`operate` .
 
-Below are the complete steps to install a physical cluster. It assumes
-``kubectl`` and ``helm`` commands are already available.
+HA Cluster
+----------
 
-Configure Helm
---------------
+To deploy ONOS in a multi instance environment for redundancy, High avaliablity and scale, you can add
+`NUM_OF_ONOS=3 NUM_OF_ATOMIX=3` to any of the workflow command. You can pick the number of instances onf ONOS
+and ATOMIX independently. As a good suggestion is 3 or 5.
 
-Helm provide a capability to install and manage Kubernetes applications.
-VOLTHA’s default deployment mechanism utilized Helm. Before Helm can be
-used to deploy VOLTHA it must be initialized and the repositories that
-container the artifacts required to deploy VOLTHA must be added to Helm.
+If you are planning to support a big number of ONU we suggest to horizontally scale
+the ``openonu-adapater``, you can do so by setting the ``NUM_OF_OPENONU`` variable.
+Generally speaking a single ``openonu-adapter`` instance can support up to 200 ONU devices.
+
+As an example for the ATT workflow:
 
 .. code:: bash
 
-    helm repo add incubator https://kubernetes-charts-incubator.storage.googleapis.com
-    helm repo add stable https://kubernetes-charts.storage.googleapis.com
-    helm repo add onf https://charts.opencord.org
-    helm repo update
+    WITH_RADIUS=y CONFIG_SADIS=y SADIS_CFG="my-sadis-cfg.json" NUM_OF_ONOS=3 NUM_OF_ATOMIX=3 NUM_OF_OPENONU=8 ./voltha up
 
-.. _installation_steps:
+Configuration for in-band OLT control
+-------------------------------------
 
-Install EtcdOperator
---------------------
-
-ETCD Operator is a utility that allows applications to create and manage
-ETCD key/value clusters as Kubernetes resources. VOLTHA utilizes this
-utility to create its key/value store. *NOTE: it is not required that
-VOLTHA create its own datastore as VOLTHA can utilize an existing
-datastore, but for this example VOLTHA will creates its own datastore*
-
-.. code:: bash
-
-   helm install -f $TYPE-values.yaml --namespace voltha --name etcd-operator stable/etcd-operator
-
-Wait for operator pods
-~~~~~~~~~~~~~~~~~~~~~~
-
-Before continuing, the Kubernetes pods associated with ETCD Operator must
-be in the ``Running`` state.
-
-.. code:: bash
-
-   kubectl get -n voltha pod
-
-Once all the pods are in the ``Running`` state the output, for a
-**full** deployment should be similar to the output below. For a
-**minimal** deployment there will only be a single pod, the
-``etcd-operator-etcd-operator-etcd-operator`` pod.
-
-.. code:: bash
-
-   NAME                                                              READY     STATUS    RESTARTS   AGE
-   etcd-operator-etcd-operator-etcd-backup-operator-7897665cfq75w2   1/1       Running   0          2m
-   etcd-operator-etcd-operator-etcd-operator-7d579799f7-bjdnj        1/1       Running   0          2m
-   etcd-operator-etcd-operator-etcd-restore-operator-7d77d878wwcn7   1/1       Running   0          2m
-
-It is not just VOLTHA
----------------------
-
-To demonstrate the capability of VOLTHA other *partner* applications are
-required, such as ONOS. The following sections describe how to install
-and configure these *partner* applications.
-
-*NOTE: It is important to start ONOS before VOLTHA as if they are started in
-the reverse order the ``ofagent`` sometimes does not connect to the SDN
-controller*\ `VOL-1764 <https://jira.opencord.org/browse/VOL-1764>`__.
-
-ONOS (OpenFlow Controller)
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-VOLTHA exposes an OLT and its connected ONUs as an OpenFlow switch. To control
-that virtual OpenFlow switch an OpenFlow controller is required.  For most
-VOLTHA deployments that controller is ONOS, with a set of ONOS applications
-installed. To install ONOS use the following Helm command:
-
-.. code:: bash
-
-   helm install -f $TYPE-values.yaml --name onos onf/onos
-
-Exposing ONOS Services
-^^^^^^^^^^^^^^^^^^^^^^
-
-.. code:: bash
-
-   screen -dmS onos-ui kubectl port-forward service/onos-ui 8181:8181
-   screen -dmS onos-ssh kubectl port-forward service/onos-ssh 8101:8101
-
-Configuring ONOS Applications
-^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-
-Configuration files have been provided to configure aspects of the ONOS
-deployment. The following curl commands push those configurations to the
-ONOS instance. It is possible (likely) that ONOS won’t be immediately
-ready to accept REST requests, so the first ``curl`` command may need
-retried until ONOS is ready to accept REST connections.
-
-.. code:: bash
-
-   curl --fail -sSL --user karaf:karaf \
-       -X POST -H Content-Type:application/json \
-       http://127.0.0.1:8181/onos/v1/network/configuration/apps/org.opencord.kafka \
-       --data @onos-files/onos-kafka.json
-   curl --fail -sSL --user karaf:karaf \
-       -X POST -H Content-Type:application/json \
-       http://127.0.0.1:8181/onos/v1/network/configuration/apps/org.opencord.dhcpl2relay \
-       --data @onos-files/onos-dhcpl2relay.json
-   curl --fail -sSL --user karaf:karaf \
-       -X POST -H Content-Type:application/json \
-       http://127.0.0.1:8181/onos/v1/configuration/org.opencord.olt.impl.Olt \
-       --data @onos-files/olt-onos-olt-settings.json
-   curl --fail -sSL --user karaf:karaf \
-       -X POST -H Content-Type:application/json \
-       http://127.0.0.1:8181/onos/v1/configuration/org.onosproject.net.flow.impl.FlowRuleManager \
-       --data @onos-files/olt-onos-enableExtraneousRules.json
-
-SADIS Configuration
-^^^^^^^^^^^^^^^^^^^
-
-The ONOS applications leverage the *Subscriber and Device Information
-Store (SADIS)* when processing EAPOL and DHCP packets from VOLTHA
-controlled devices. In order for VOLTHA to function properly, SADIS
-entries must be configured into ONOS.
-
-The repository contains two example SADIS configuration that can be used
-with ONOS depending if you using VOLTHA with *tech profile* support
-(``onos-files/onos-sadis-no-tp.json``) or without *tech profile* support
-(``onos-files/onos-sadis-tp.json``). Either of these configurations can
-be pushed to ONOS using the following command:
-
-.. code:: bash
-
-   curl --fail -sSL --user karaf:karaf \
-       -X POST -H Content-Type:application/json \
-       http://127.0.0.1:8181/onos/v1/network/configuration/apps/org.opencord.sadis \
-       --data @<selected SADIS configuration file>
-
-Install VOLTHA Core
--------------------
-
-VOLTHA has two main *parts*: core and adapters. The **core** provides
-the main logic for the VOLTHA application and the **adapters** contain
-logic to adapter vendor neutral operations to vendor specific devices.
-
-Before any adapters can be deployed the VOLTHA core must be installed
-and in the ``Running`` state. The following Helm command installs the
-core components of VOLTHA based on the desired deployment type.
-
-.. code:: bash
-
-   helm install -f $TYPE-values.yaml --set use_go=true --set defaults.log_level=WARN \
-       --namespace voltha --name voltha onf/voltha
-
-During the install of the core VOLTHA components some containers may
-"crash" or restart. This is normal as there are dependencies, such as
-the read/write cores cannot start until the ETCD cluster is established
-and so they crash until the ETCD cluster is operational. Eventually all
-the containers should be in a ``Running`` state as queried by the
-command:
-
-.. code:: bash
-
-   kubectl get -n voltha pod
-
-The output should be similar to the following with a different number of
-``etcd-operator`` and ``voltha-etcd-cluster`` pods depending on the
-deployment type.
-
-.. code:: bash
-
-   NAME                                                         READY     STATUS    RESTARTS   AGE
-   etcd-operator-etcd-operator-etcd-operator-7d579799f7-xq6f2   1/1       Running   0          19m
-   ofagent-8ccb7f5fb-hwgfn                                      1/1       Running   0          4m
-   ro-core-564f5cdcc7-2pch8                                     1/1       Running   0          4m
-   rw-core1-7fbb878cdd-6npvr                                    1/1       Running   2          4m
-   rw-core2-7fbb878cdd-k7w9j                                    1/1       Running   3          4m
-   voltha-api-server-5f7c8b5b77-k6mrg                           2/2       Running   0          4m
-   voltha-cli-server-5df4c95b7f-kcpdl                           1/1       Running   0          4m
-   voltha-etcd-cluster-4rsqcvpwr4                               1/1       Running   0          4m
-   voltha-kafka-0                                               1/1       Running   0          4m
-   voltha-zookeeper-0                                           1/1       Running   0          4m
-
-Install Adapters
-----------------
-
-The following commands install both the simulated OLT and ONU adapters
-as well as the adapters for an OpenOLT and OpenONU device.
-
-.. code:: bash
-
-   helm install -f $TYPE-values.yaml -set use_go=true --set defaults.log_level=WARN \
-       --namespace voltha --name sim onf/voltha-adapter-simulated
-   helm install -f $TYPE-values.yaml -set use_go=true --set defaults.log_level=WARN \
-       --namespace voltha --name open-olt onf/voltha-adapter-openolt
-   helm install -f $TYPE-values.yaml -set use_go=true --set defaults.log_level=WARN \
-       --namespace voltha --name open-onu onf/voltha-adapter-openonu
-
-Exposing VOLTHA Services
-------------------------
-
-At this point VOLTHA is deployed, and from within the Kubernetes cluster
-the VOLTHA services can be reached. However, from outside the Kubernetes
-cluster the services cannot be reached.
-
-.. code:: bash
-
-   screen -dmS voltha-api kubectl port-forward -n voltha service/voltha-api 55555:55555
-   screen -dmS voltha-ssh kubectl port-forward -n voltha service/voltha-cli 5022:5022
-
-Install FreeRADIUS Service
---------------------------
-
-.. code:: bash
-
-   helm install -f minimal-values.yaml --namespace voltha --name radius onf/freeradius
-
-Configure ``voltctl`` to Connect to VOLTHA
-------------------------------------------
-
-In order for ``voltctl`` to connect to the VOLTHA instance deployed in
-the Kubernetes cluster it must know which IP address and port to use.
-This configuration can be persisted to a local config file using the
-following commands.
-
-.. code:: bash
-
-   mkdir -p $HOME/.volt
-   voltctl -a v2 -s localhost:55555 config > $HOME/.volt/config
-
-To test the connectivity you can query the version of the VOLTHA client
-and server::
-
-   voltctl version
-
-The output should be similar to the following::
-
-   Client:
-    Version        unknown-version
-    Go version:    unknown-goversion
-    Vcs reference: unknown-vcsref
-    Vcs dirty:     unknown-vcsdirty
-    Built:         unknown-buildtime
-    OS/Arch:       unknown-os/unknown-arch
-
-   Cluster:
-    Version        2.1.0-dev
-    Go version:    1.12.6
-    Vcs feference: 28f120f1f4751284cadccf73f2f559ce838dd0a5
-    Vcs dirty:     false
-    Built:         2019-06-26T16:58:22Z
-    OS/Arch:       linux/amd64
+If OLT is being used in in-band connectivity mode, the following
+`document <https://docs.google.com/document/d/1OKDJCPEFVTEythAFUS_I7Piew4jHmhk25llK6UF04Wg>`_
+details the configuration aspects in ONOS and the aggregation switch to
+trunk/switch in-band packets from the OLT to BNG or Voltha.
diff --git a/overview/quickstart.rst b/overview/quickstart.rst
new file mode 100644
index 0000000..18e5fbc
--- /dev/null
+++ b/overview/quickstart.rst
@@ -0,0 +1,77 @@
+.. _quickstart:
+
+Quickstart
+==========
+
+This page contains a set of one liner useful to setup different VOLTHA use-cases on
+a Virtual pod emulating the PON through :doc:`BBSim <../bbsim/docs/source/index>`.
+
+For more information on how to setup a :doc:`physical POD <./pod_physical>` or
+use a :doc:`Virtual POD <./dev_virtual>` for development
+refer to the respective guides.
+
+Common setup
+------------
+
+In order to install VOLTHA you need to have ``golang`` and ``docker`` installed.
+
+.. code:: bash
+
+    export KINDVOLTHADIR=~/kind-voltha
+    mkdir $KINDVOLTHADIR
+    cd $KINDVOLTHADIR
+    curl -sSL https://raw.githubusercontent.com/opencord/kind-voltha/master/voltha --output ./voltha
+    chmod +x ./voltha
+
+Now select the use-case you want to deploy:
+
+ATT Workflow
+------------
+
+The ATT Workflow expects EAPOL based authentication and DHCP to be handled within
+the VOLTHA POD.
+
+.. code:: bash
+
+    cd $KINDVOLTHADIR
+    WITH_BBSIM="yes" WITH_EAPOL="yes" WITH_DHCP="yes" WITH_RADIUS="yes" CONFIG_SADIS="bbsim" ./voltha up
+
+DT Workflow
+------------
+
+The DT workflow does not require EAPOL based authentication or DHCP packet handling
+in the VOLTHA POD.
+
+.. code:: bash
+
+    cd $KINDVOLTHADIR
+    WITH_BBSIM="yes" WITH_EAPOL="no" WITH_DHCP="no" CONFIG_SADIS="bbsim" EXTRA_HELM_FLAGS="--set bbsim.sadisFormat=dt" ./voltha up
+
+TT Workflow
+------------
+
+The TT workflow does not require EAPOL based authentication but expects DHCP packets
+for multiple services to be handled within the POD.
+
+*Note that the TT workflow is not fully supported yet*
+
+.. code:: bash
+
+    cd $KINDVOLTHADIR
+    WITH_BBSIM="yes" WITH_EAPOL="no" WITH_DHCP="yes" CONFIG_SADIS="bbsim" EXTRA_HELM_FLAGS="--set bbsim.sadisFormat=tt" ./voltha up
+
+Post deploy actions
+-------------------
+
+Once the deployment completed, make sure to export the required ``environment``
+variables as ``kind-voltha`` outputs:
+
+.. code:: bash
+
+    export KUBECONFIG="/Users/teone/.kube/kind-config-voltha-minimal"
+    export VOLTCONFIG="/Users/teone/.volt/config-minimal"
+    export PATH=/Users/teone/kind-voltha/bin:$PATH
+
+Once you have the POD up and running you can refer to the :doc:`./operate` guide.
+
+For more information please check :doc:`kind-voltha page <../kind-voltha/README>`.
diff --git a/overview/ubuntu_dev_env.rst b/overview/ubuntu_dev_env.rst
deleted file mode 100644
index 36b9901..0000000
--- a/overview/ubuntu_dev_env.rst
+++ /dev/null
@@ -1,510 +0,0 @@
-Setting up an Ubuntu Development Environment
-============================================
-
-These notes describe the checking out and building from the multiple
-gerrit repositories needed to run a VOLTHA 2.x environment with
-docker-compose. Starting point is a basic Ubuntu 16.04 or 18.04
-installation with internet access.
-
-These notes are intended for iterative development only. The testing
-environments and production environments will run a Kubernetes and Helm
-based deployment.
-
-Install prerequisites
----------------------
-
-Patch and updated
-
-.. code:: sh
-
-   sudo apt update
-   sudo apt dist-upgrade
-
-Add ``docker-ce`` apt repo and install docker and build tools
-
-.. code:: sh
-
-   curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add -
-   sudo add-apt-repository "deb [arch=amd64] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable"
-   sudo apt update
-   sudo apt install build-essential docker-ce git
-
-Install current ``docker-compose``. Older versions may cause docker
-build problems:
-https://github.com/docker/docker-credential-helpers/issues/103
-
-.. code:: sh
-
-   sudo curl -L "https://github.com/docker/compose/releases/download/1.25.0/docker-compose-$(uname -s)-$(uname -m)" -o /usr/local/bin/docker-compose
-   sudo chmod 755 /usr/local/bin/docker-compose
-
-Install the Golang ppa apt repository and install **golang 1.13**.
-
-.. code:: sh
-
-   sudo add-apt-repository ppa:longsleep/golang-backports
-   sudo apt update
-   sudo apt install golang-1.13
-
-Setup environment
-~~~~~~~~~~~~~~~~~
-
-Setup a local Golang and docker-compose environment, verifying the
-golang-1.13 binaries are in your path. Also add your local ``GOPATH``
-bin folder to ``PATH`` Add export statements to your ``~/.profile`` to
-persist.
-
-.. code:: sh
-
-   mkdir $HOME/source
-   mkdir $HOME/go
-   export GO111MODULE=on
-   export GOPATH=$HOME/go
-   export DOCKER_TAG=latest
-   export PATH=$PATH:/usr/lib/go-1.13/bin:$GOPATH/bin
-   go version
-
-Allow your current non-root user ``$USER`` docker system access
-
-.. code:: sh
-
-   sudo usermod -a -G docker $USER
-
-Logout/Login to assume new group membership needed for running docker as
-non-root user and verify any environment variables set in
-``~/.profile``.
-
-Checkout source and build images
---------------------------------
-
-VOLTHA 2.x Core Containers
-~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Checkout needed source from gerrit. Build the ``voltha-rw-core`` docker
-image.
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/voltha-go.git
-   cd ~/source/voltha-go
-   make build
-
-For more details regarding building and debugging the 2.x core outside
-of Docker refer to voltha-go BUILD.md.
-
-https://github.com/opencord/voltha-go/blob/master/BUILD.md
-
-VOLTHA 2.x OpenOLT Container
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Checkout needed source from gerrit. Build the ``voltha-openolt-adapter``
-docker image.
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/voltha-openolt-adapter.git
-   cd ~/source/voltha-openolt-adapter/
-   make build
-
-VOLTHA 2.x OpenONU Container
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Checkout needed source from gerrit. Build the ``voltha-openonu-adapter``
-docker image.
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/voltha-openonu-adapter.git
-   cd ~/source/voltha-openonu-adapter/
-   make build
-
-VOLTHA 2.x OFAgent
-~~~~~~~~~~~~~~~~~~
-
-Checkout needed source from gerrit. Build the ``voltha-ofagent`` docker
-image.
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/ofagent-go.git
-   cd ~/source/ofagent-go/
-   make docker-build
-
-ONOS Container with VOLTHA Compatible Apps
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-By default the standard ONOS docker image does not contain nor start any
-apps needed by VOLTHA. If you use the standard image then you need to
-use the ONOS restful API to load needed apps separately.
-
-For development convenience there is an ONOS docker image build that
-adds in the current compatible VOLTHA apps. Checkout and build the ONOS
-image with added ONOS apps (olt, aaa, sadis, dhcpl2relay, and kafka).
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/voltha-onos.git
-   cd ~/source/voltha-onos
-   make build
-
-Install voltctl VOLTHA Command Line Management Tool
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-A working Golang build environment is required as ``voltctl`` is build
-and run directly from the host. Build the ``voltctl`` executable and
-install in ~/go/bin which should already be in your $PATH
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/voltctl.git
-   cd ~/source/voltctl
-   make build
-   make install
-
-Configure the ``voltctl`` environment configuration files
-``~/.volt/config`` and ``~/.volt/command_options`` to point at the local
-``voltha-rw-core`` instance that will be running.
-
-.. code:: sh
-
-   mkdir ~/.volt/
-
-   cat << EOF > ~/.volt/config
-   apiVersion: v2
-   server: localhost:50057
-   tls:
-     useTls: false
-     caCert: ""
-     cert: ""
-     key: ""
-     verify: ""
-   grpc:
-     timeout: 10s
-   EOF
-
-   cat << EOF > ~/.volt/command_options
-   device-list:
-     format: table{{.Id}}\t{{.Type}}\t{{.Root}}\t{{.ParentId}}\t{{.SerialNumber}}\t{{.Address}}\t{{.AdminState}}\t{{.OperStatus}}\t{{.ConnectStatus}}\t{{.Reason}}
-     order: -Root,SerialNumber
-
-   device-ports:
-     order: PortNo
-
-   device-flows:
-     order: Priority,EthType
-
-   logical-device-list:
-     order: RootDeviceId,DataPathId
-
-   logical-device-ports:
-     order: Id
-
-   logical-device-flows:
-     order: Priority,EthType
-
-   adapter-list:
-     order: Id
-
-   component-list:
-     order: Component,Name,Id
-
-   loglevel-get:
-     order: ComponentName,PackageName,Level
-
-   loglevel-list:
-     order: ComponentName,PackageName,Level
-   EOF
-
-
-Install VOLTHA bbsim olt/onu Simulator (Optional)
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you do not have physical OLT/ONU hardware you can build a simulator.
-
-.. code:: sh
-
-   cd ~/source/
-   git clone https://gerrit.opencord.org/bbsim.git
-   cd ~/source/bbsim
-   make docker-build
-
-Test
-----
-
-Startup
-~~~~~~~
-
-Run the combined docker-compose yaml configuration file that starts the
-core, its dependent systems (etcd, zookeeper, and kafka) and the openonu
-and openolt adapters. Export the ``DOCKER_HOST_IP`` environment variable
-to your non-localhost IP address needed for inter-container
-communication. This can be the IP assigned to ``eth0`` or the
-``docker0`` bridge (typically 172.17.0.1)
-
-For convenience you can also export ``DOCKER_TAG`` to signify the docker
-images tag you would like to use. Though for typical development you may
-have to edit ``compose/system-test.yml`` to override the specific docker
-image ``DOCKER_TAG`` needed. The ``DOCKER_REGISTRY`` and
-``DOCKER_REPOSITORY`` variables are not needed unless you wish to
-override the docker image path. See the ``system-test.yml`` file for
-details on the docker image path creation string.
-
-.. code:: sh
-
-   export DOCKER_HOST_IP=172.17.0.1
-   export DOCKER_TAG=latest
-
-   cd ~/source/voltha-go
-   docker-compose -f compose/system-test.yml up -d
-
-
-   WARNING: The DOCKER_REGISTRY variable is not set. Defaulting to a blank string.
-   WARNING: The DOCKER_REPOSITORY variable is not set. Defaulting to a blank string.
-   Creating network "compose_default" with driver "bridge"
-   Pulling zookeeper (wurstmeister/zookeeper:latest)...
-   latest: Pulling from wurstmeister/zookeeper
-   a3ed95caeb02: Pull complete
-   ef38b711a50f: Pull complete
-   e057c74597c7: Pull complete
-   666c214f6385: Pull complete
-   c3d6a96f1ffc: Pull complete
-   3fe26a83e0ca: Pull complete
-   3d3a7dd3a3b1: Pull complete
-   f8cc938abe5f: Pull complete
-   9978b75f7a58: Pull complete
-   4d4dbcc8f8cc: Pull complete
-   8b130a9baa49: Pull complete
-   6b9611650a73: Pull complete
-   5df5aac51927: Pull complete
-   76eea4448d9b: Pull complete
-   8b66990876c6: Pull complete
-   f0dd38204b6f: Pull complete
-   Digest: sha256:7a7fd44a72104bfbd24a77844bad5fabc86485b036f988ea927d1780782a6680
-   Status: Downloaded newer image for wurstmeister/zookeeper:latest
-   Pulling kafka (wurstmeister/kafka:2.11-2.0.1)...
-   2.11-2.0.1: Pulling from wurstmeister/kafka
-   4fe2ade4980c: Pull complete
-   6fc58a8d4ae4: Pull complete
-   819f4a45746c: Pull complete
-   a3133bc2e3e5: Pull complete
-   72f0dc369677: Pull complete
-   1e1130fc942d: Pull complete
-   Digest: sha256:20d08a6849383b124bccbe58bc9c48ec202eefb373d05e0a11e186459b84f2a0
-   Status: Downloaded newer image for wurstmeister/kafka:2.11-2.0.1
-   Pulling etcd (quay.io/coreos/etcd:v3.2.9)...
-   v3.2.9: Pulling from coreos/etcd
-   88286f41530e: Pull complete
-   2fa4a2c3ffb5: Pull complete
-   539b8e6ccce1: Pull complete
-   79e70e608afa: Pull complete
-   f1bf8f503bff: Pull complete
-   c4abfc27d146: Pull complete
-   Digest: sha256:1913dd980d55490fa50640bbef0f4540d124e5c66d6db271b0b4456e9370a272
-   Status: Downloaded newer image for quay.io/coreos/etcd:v3.2.9
-   Creating compose_kafka_1           ... done
-   Creating compose_cli_1             ... done
-   Creating compose_adapter_openolt_1 ... done
-   Creating compose_rw_core_1         ... done
-   Creating compose_adapter_openonu_1 ... done
-   Creating compose_etcd_1            ... done
-   Creating compose_onos_1            ... done
-   Creating compose_ofagent_1         ... done
-   Creating compose_zookeeper_1       ... done
-
-Verify containers have continuous uptime and no restarts
-
-.. code:: sh
-
-   $ docker-compose -f compose/system-test.yml ps
-   WARNING: The DOCKER_REGISTRY variable is not set. Defaulting to a blank string.
-   WARNING: The DOCKER_REPOSITORY variable is not set. Defaulting to a blank string.
-             Name                         Command               State                                             Ports
-   ---------------------------------------------------------------------------------------------------------------------------------------------------------------
-   compose_adapter_openolt_1   /app/openolt --kafka_adapt ...   Up      0.0.0.0:50062->50062/tcp
-   compose_adapter_openonu_1   /voltha/adapters/brcm_open ...   Up
-   compose_etcd_1              etcd --name=etcd0 --advert ...   Up      0.0.0.0:2379->2379/tcp, 0.0.0.0:32929->2380/tcp, 0.0.0.0:32928->4001/tcp
-   compose_kafka_1             start-kafka.sh                   Up      0.0.0.0:9092->9092/tcp
-   compose_ofagent_1           /app/ofagent --controller= ...   Up
-   compose_onos_1              ./bin/onos-service server        Up      6640/tcp, 0.0.0.0:6653->6653/tcp, 0.0.0.0:8101->8101/tcp, 0.0.0.0:8181->8181/tcp, 9876/tcp
-   compose_rw_core_1           /app/rw_core -kv_store_typ ...   Up      0.0.0.0:50057->50057/tcp
-   compose_zookeeper_1         /bin/sh -c /usr/sbin/sshd  ...   Up      0.0.0.0:2181->2181/tcp, 22/tcp, 2888/tcp, 3888/tcp
-
-.. code:: sh
-
-   $ docker ps
-   CONTAINER ID        IMAGE                           COMMAND                  CREATED             STATUS              PORTS                                                                                        NAMES
-   08a0e7a1ee5c        voltha-openolt-adapter:latest   "/app/openolt --kafk…"   31 seconds ago      Up 27 seconds       0.0.0.0:50062->50062/tcp                                                                     compose_adapter_openolt_1
-   1f364cf7912d        wurstmeister/zookeeper:latest   "/bin/sh -c '/usr/sb…"   31 seconds ago      Up 27 seconds       22/tcp, 2888/tcp, 3888/tcp, 0.0.0.0:2181->2181/tcp                                           compose_zookeeper_1
-   ab1822baed41        wurstmeister/kafka:2.11-2.0.1   "start-kafka.sh"         31 seconds ago      Up 24 seconds       0.0.0.0:9092->9092/tcp                                                                       compose_kafka_1
-   22a4fe4b2eb4        voltha-ofagent-go:latest        "/app/ofagent --cont…"   31 seconds ago      Up 23 seconds                                                                                                    compose_ofagent_1
-   d34e1c976db5        voltha-rw-core:latest           "/app/rw_core -kv_st…"   31 seconds ago      Up 26 seconds       0.0.0.0:50057->50057/tcp                                                                     compose_rw_core_1
-   f6ef52975dc0        voltha-openonu-adapter:latest   "/voltha/adapters/br…"   31 seconds ago      Up 29 seconds                                                                                                    compose_adapter_openonu_1
-   7ce8bcf7436c        voltha-onos:latest              "./bin/onos-service …"   31 seconds ago      Up 25 seconds       0.0.0.0:6653->6653/tcp, 0.0.0.0:8101->8101/tcp, 6640/tcp, 9876/tcp, 0.0.0.0:8181->8181/tcp   compose_onos_1
-   60ac172726f5        quay.io/coreos/etcd:v3.4.1      "etcd --name=etcd0 -…"   31 seconds ago      Up 28 seconds       0.0.0.0:2379->2379/tcp, 0.0.0.0:32931->2380/tcp, 0.0.0.0:32930->4001/tcp                     compose_etcd_1
-
-Verify Cluster Communication
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Use ``voltctl`` commands to verify core and adapters are running.
-
-.. code:: sh
-
-   voltctl adapter list
-   ID                   VENDOR            VERSION      SINCELASTCOMMUNICATION
-   brcm_openomci_onu    VOLTHA OpenONU    2.3.2-dev    UNKNOWN
-   openolt              VOLTHA OpenOLT    2.3.5-dev    UNKNOWN
-
-List “devices” to verify no devices exist.
-
-.. code:: sh
-
-   voltctl device list
-   ID    TYPE    ROOT    PARENTID    SERIALNUMBER    ADDRESS    ADMINSTATE    OPERSTATUS    CONNECTSTATUS    REASON
-
-At this point create/preprovision and enable an olt device and add flows
-via onos and ofagent.
-
-Physical OLT/ONU Testing with Passing Traffic
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Start a physical OLT and ONU. Tested with Edgecore OLT, Broadcom based
-ONU, and RG capable of EAPoL. Create/Preprovision the OLT and enable.
-The create command returns the device ID needed for enable and
-subsequent commands.
-
-**Add device to VOLTHA**
-
-.. code:: sh
-
-   $ voltctl device create -t openolt -H 10.64.1.206:9191
-   db87c4b48843bb99567d3d94
-
-   $ voltctl device enable db87c4b48843bb99567d3d94
-   db87c4b48843bb99567d3d94
-
-**Verify device state**
-
-.. code:: sh
-
-   $ voltctl device list
-   ID                          TYPE                 ROOT     PARENTID                    SERIALNUMBER    ADDRESS             ADMINSTATE    OPERSTATUS    CONNECTSTATUS    REASON
-   db87c4b48843bb99567d3d94    openolt              true     a82bb53678ae                EC1721000221    10.64.1.206:9191    ENABLED       ACTIVE        REACHABLE
-   082d7c2e628325ccc3336275    brcm_openomci_onu    false    db87c4b48843bb99567d3d94    ALPHe3d1cf57    unknown             ENABLED       ACTIVE        REACHABLE        omci-flows-pushed
-
-.. code:: sh
-
-   $ voltctl device port list db87c4b48843bb99567d3d94
-   PORTNO       LABEL            TYPE            ADMINSTATE    OPERSTATUS    DEVICEID    PEERS
-   1048576      nni-1048576      ETHERNET_NNI    ENABLED       ACTIVE                    []
-   536870912    pon-536870912    PON_OLT         ENABLED       ACTIVE                    [{082d7c2e628325ccc3336275 536870912}]
-   536870913    pon-536870913    PON_OLT         ENABLED       ACTIVE                    []
-   536870914    pon-536870914    PON_OLT         ENABLED       ACTIVE                    []
-   536870915    pon-536870915    PON_OLT         ENABLED       ACTIVE                    []
-   536870916    pon-536870916    PON_OLT         ENABLED       ACTIVE                    []
-   536870917    pon-536870917    PON_OLT         ENABLED       ACTIVE                    []
-   536870918    pon-536870918    PON_OLT         ENABLED       ACTIVE                    []
-   536870919    pon-536870919    PON_OLT         ENABLED       ACTIVE                    []
-   536870920    pon-536870920    PON_OLT         ENABLED       ACTIVE                    []
-   536870921    pon-536870921    PON_OLT         ENABLED       ACTIVE                    []
-   536870922    pon-536870922    PON_OLT         ENABLED       ACTIVE                    []
-   536870923    pon-536870923    PON_OLT         ENABLED       ACTIVE                    []
-   536870924    pon-536870924    PON_OLT         ENABLED       ACTIVE                    []
-   536870925    pon-536870925    PON_OLT         ENABLED       ACTIVE                    []
-   536870926    pon-536870926    PON_OLT         ENABLED       ACTIVE                    []
-   536870927    pon-536870927    PON_OLT         ENABLED       ACTIVE                    []
-
-.. code:: sh
-
-   $ voltctl device port list 082d7c2e628325ccc3336275
-   PORTNO       LABEL       TYPE            ADMINSTATE    OPERSTATUS    DEVICEID    PEERS
-   16           uni-16      ETHERNET_UNI    ENABLED       ACTIVE                    []
-   17           uni-17      ETHERNET_UNI    ENABLED       DISCOVERED                []
-   18           uni-18      ETHERNET_UNI    ENABLED       DISCOVERED                []
-   19           uni-19      ETHERNET_UNI    ENABLED       DISCOVERED                []
-   20           uni-20      ETHERNET_UNI    ENABLED       DISCOVERED                []
-   536870912    PON port    PON_ONU         ENABLED       ACTIVE                    [{db87c4b48843bb99567d3d94 536870912}]
-
-Verify ONOS device state and eventual EAPoL authentication. ONOS default
-Username is ``karaf``, Password is ``karaf``
-
-.. code:: sh
-
-   ssh -p 8101 karaf@localhost
-
-Display the device and ports discovered
-
-.. code:: sh
-
-   karaf@root > ports
-
-   id=of:0000a82bb53678ae, available=true, local-status=connected 4m27s ago, role=MASTER, type=SWITCH, mfr=VOLTHA Project, hw=open_pon, sw=open_pon, serial=EC1721000221, chassis=a82bb53678ae, driver=voltha, channelId=172.27.0.1:59124, managementAddress=172.27.0.1, protocol=OF_13
-     port=16, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:10, portName=ALPHe3d1cf57-1
-     port=17, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:11, portName=ALPHe3d1cf57-2
-     port=18, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:12, portName=ALPHe3d1cf57-3
-     port=19, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:13, portName=ALPHe3d1cf57-4
-     port=20, state=disabled, type=fiber, speed=0 , adminState=enabled, portMac=08:00:00:00:00:14, portName=ALPHe3d1cf57-5
-     port=1048576, state=enabled, type=fiber, speed=0 , adminState=enabled, portMac=a8:2b:b5:36:78:ae, portName=nni-1048576
-
-EAPoL may take up to 30 seconds to complete.
-
-.. code:: sh
-
-   karaf@root > aaa-users
-
-   of:0000a82bb53678ae/16: AUTHORIZED_STATE, last-changed=4m22s ago, mac=94:CC:B9:DA:AB:D1, subid=PON 1/1/3/1:2.1.1, username=94:CC:B9:DA:AB:D1
-
-**Provision subscriber flows**
-
-.. code:: sh
-
-   karaf@root > volt-add-subscriber-access of:0000a82bb53678ae 16
-
-   karaf@root > volt-programmed-subscribers
-
-   location=of:0000a82bb53678ae/16 tagInformation=UniTagInformation{uniTagMatch=0, ponCTag=20, ponSTag=11, usPonCTagPriority=-1, usPonSTagPriority=-1, dsPonCTagPriority=-1, dsPonSTagPriority=-1, technologyProfileId=64, enableMacLearning=false, upstreamBandwidthProfile='Default', downstreamBandwidthProfile='Default', serviceName='', configuredMacAddress='A4:23:05:00:00:00', isDhcpRequired=true, isIgmpRequired=false}
-
-After about 30 seconds the RG should attempt DHCP which should be
-visible in onos. At this point the RG should be able to pass database
-traffic via the ONU/OLT.
-
-.. code:: sh
-
-   karaf@root > dhcpl2relay-allocations
-
-   SubscriberId=ALPHe3d1cf57-1,ConnectPoint=of:0000a82bb53678ae/16,State=DHCPREQUEST,MAC=94:CC:B9:DA:AB:D1,CircuitId=PON 1/1/3/1:2.1.1,IP Allocated=29.29.206.20,Allocation Timestamp=2020-02-17T15:34:31.572746Z
-
-BBSIM Simulated OLT/ONU Testing Control Plane Traffic
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-If you do not have physical OLT/ONU hardware you can start VOLTHA
-containers and the bbsim olt/onu hardware simulator using a different
-docker-compose yaml file. Verify containers are running as above with
-the addition of the bbsim and radius server containers.
-
-.. code:: sh
-
-   export DOCKER_HOST_IP=172.17.0.1
-   export DOCKER_TAG=latest
-
-   cd ~/source/voltha-go
-   docker-compose -f compose/system-test-bbsim.yml up -d
-
-Create/Preprovision and enable similarly to the physical OLT above,
-providing the local bbsim IP and listening port
-
-.. code:: sh
-
-   voltctl device create -t openolt -H 172.17.0.1:50060
-   ece94c86e93c6e06dd0a544b
-
-   voltctl device enable ece94c86e93c6e06dd0a544b
-   ece94c86e93c6e06dd0a544b
-
-Proceed with the verification and ONOS provisioning commands similar to
-the physical OLT described above.
diff --git a/overview/workflows.rst b/overview/workflows.rst
new file mode 100644
index 0000000..25bb7e6
--- /dev/null
+++ b/overview/workflows.rst
@@ -0,0 +1,101 @@
+.. _workflows:
+
+Operator workflows
+==================
+
+``Workflow`` is a term that spilled from the SEBA Reference Design (RD) into VOLTHA.
+
+In SEBA a workflow is defined as the set of operations that control the lifecycle
+of a subscriber, authentication logic, customer tag management etc... Such workflow is operator specific.
+
+A full description of the workflows can be `found here <https://drive.google.com/drive/folders/1MfxwoDSvAR_rgFHt6n9Sai7IuiJPrHxF>`_.
+
+A big part of the workflow in SEBA is defined within NEM (Network Edge Mediator).
+Given that NEM is not available in a plain VOLTHA deployment the definition
+of workflow is a subset of the SEBA one, and comprises:
+
+- Customer tags allocation
+- Technology profile
+- Bandwidth profile
+- Flow management (EAPOL/DHCP/Data path)
+- Group management
+
+The `workflows` are often referred to as `use-cases` and the two words are interchangeable
+in the VOLTHA environment.
+
+To deploy a specific workflow through ``kind-voltha`` please visit :ref:`quickstart`.
+
+How is the workflow defined in VOLTHA?
+----------------------------------------
+
+Customer tag allocation
+***********************
+
+The vlan tags for a particular subscriber are defined in the ``sadis`` configuration.
+`Sadis <https://github.com/opencord/sadis>`_ stands for `Subscriber and Device Information Service`
+and is the ONOS application responsible to store and distribute Subscriber information.
+
+Information on different ``sadis`` configurations can be found here:
+https://docs.google.com/document/d/1JLQ51CZg4jsXsBQcrJn-fc2kVvXH6lw0PYoyIclwmBs
+
+Technology profile
+******************
+
+Technology profiles describes technology specific attributes required to implement
+Subscriber Services on an OpenFlow managed Logical Switch overlaid upon an OLT
+or other technology specific platform.
+
+More on Technology profiles here:
+https://wiki.opencord.org/display/CORD/Technology+Profiles#TechnologyProfiles-IntroductiontoTechnologyProfiles
+
+Technology profiles in VOLTHA are stored in ETCD. If you want to load a custom
+Technology profile in your stack you can do so by:
+
+.. code:: bash
+
+    ETCD_POD=$(kubectl get pods | grep etcd | awk 'NR==1{print \$1}')
+    kubectl cp <my-tech-profile>.json $ETCD_POD:/tmp/tp.json
+    kubectl exec -it $ETCD_POD -- /bin/sh -c 'cat /tmp/tp.json | ETCDCTL_API=3 etcdctl put service/voltha/technology_profiles/XGS-PON/64'
+
+*Note that `XGS-PON` represents the technology of your OLT device and `64` is
+the default id of the technology profile. If you want to use a technology profile
+that is not the default for a particular subscriber that needs to be configured
+in `sadis`.*
+
+Bandwidth profile
+*****************
+
+Bandwidth profiles control the allocation Bandwidth for a particular subscriber.
+They are defined in the `sadis`.
+An example:
+
+.. code-block:: json
+
+    {
+      "id" : "Default",
+      "cir" : 1000000,
+      "cbs" : 1001,
+      "eir" : 1002,
+      "ebs" : 1003,
+      "air" : 1004
+    }
+
+Each bandwidth profile is then translated into an OpenFlow Meter for configuration on the OLT.
+
+Flow management
+***************
+
+Flows are managed in ONOS by the `olt` application. Through the configuration of
+this application you can define whether your setup will create:
+
+- An `EAPOL` trap flow
+- A `DHCP` trap flow
+- An `IGMP` trap flow
+
+in addition to the default data plane flows.
+
+Group management
+****************
+
+Groups are managed in ONOS by the `mcast` application. Through the configuration of
+this application you can achieve multicast for services such as IpTV.