FDS DVR doc - Updated components diagram

Change-Id: I90f50f2781f3ca70ae6204883f330328303d3a03
Signed-off-by: Frank <fbrockne@cisco.com>

5 files changed, 13 insertions, 12 deletions

diff --git a/docs/scenarios/os-odl-fdio-dvr-noha/FDS-basic-components.jpg b/docs/scenarios/os-odl-fdio-dvr-noha/FDS-basic-components.jpg
deleted file mode 100755
index e92851f..0000000
--- a/docs/scenarios/os-odl-fdio-dvr-noha/FDS-basic-components.jpg
+++ /dev/null
diff --git a/docs/scenarios/os-odl-fdio-dvr-noha/FDS-basic-components.png b/docs/scenarios/os-odl-fdio-dvr-noha/FDS-basic-components.png
new file mode 100755
index 0000000..45f50e0
--- /dev/null
+++ b/docs/scenarios/os-odl-fdio-dvr-noha/FDS-basic-components.png
diff --git a/docs/scenarios/os-odl-fdio-dvr-noha/FDS-odl-dvr-noha-overview.png b/docs/scenarios/os-odl-fdio-dvr-noha/FDS-odl-dvr-noha-overview.png
new file mode 100755
index 0000000..b78cc6a
--- /dev/null
+++ b/docs/scenarios/os-odl-fdio-dvr-noha/FDS-odl-dvr-noha-overview.png
diff --git a/docs/scenarios/os-odl-fdio-dvr-noha/FDS-odl_l3-noha-overview.png b/docs/scenarios/os-odl-fdio-dvr-noha/FDS-odl_l3-noha-overview.png
deleted file mode 100755
index 1193ea4..0000000
--- a/docs/scenarios/os-odl-fdio-dvr-noha/FDS-odl_l3-noha-overview.png
+++ /dev/null
diff --git a/docs/scenarios/os-odl-fdio-dvr-noha/scenario.description.rst b/docs/scenarios/os-odl-fdio-dvr-noha/scenario.description.rst
index 7286a50..53969bb 100755
--- a/docs/scenarios/os-odl-fdio-dvr-noha/scenario.description.rst
+++ b/docs/scenarios/os-odl-fdio-dvr-noha/scenario.description.rst
@@ -81,11 +81,7 @@ servers:
   * 2 or more Computehosts. These Computehosts also serve as layer 3 gateways
     for tenant networks and provide ditributed virtual routing
 
-TODO: update the image:
-    1. Compute 0..N are gateways
-    2. NIC2 on controller is not in vpp
-
-.. image:: FDS-odl_l3-noha-overview.png
+.. image:: FDS-odl-dvr-noha-overview.png
 
 Tenant and public networking leverages FD.io/VPP. On compute nodes,
 VPP binds to both the tenant networking interface as well as the public
@@ -110,9 +106,6 @@ layer 3 services which are provided in a "vanilla" OpenStack deployment,
 including one-to-one NAT but not source NAT, as well as north-south and
 east-west traffic filtering for security purposes ("security groups").
 
-TODO: update the image:
-    1. Add External network interface to Computenode-1
-
 .. image:: FDS-L3-DVR-sample-setup.png
 
 Features of the scenario
@@ -204,10 +197,7 @@ interfaces.
 
 The picture below shows the key components.
 
-TODO: update the image:
-    1. Add LISP
-
-.. image:: FDS-basic-components.jpg
+.. image:: FDS-basic-components.png
 
 Neutron Port Callflow
 =====================
@@ -244,11 +234,22 @@ To provide a better understanding how the above mentioned components interact
 with each other, the following diagram shows how the example of creating a
 vhost-user port on VPP through Openstack Neutron:
 
+TODO: Add LISP components to diagram
+
 .. image:: FDS-simple-callflow.png
 
 DHCP Packet Flow
 ================
 
+DHCP traffic from a VM first arrives at vhost-user port in VPP, which is
+configured as unnumbered with ip of loopback interface (which corresponds
+with tenant interface port) for the VRF where the VM resides.
+DHCP proxy is configured to relay DHCP packets to the DHCP server created by
+neutron-dhcp-agent running on the node where the VM was created. DHCP relay
+sets the destination ip to the ip of the DHCP server and source ip to the
+loopback ip. Opendaylight configures a route for the DHCP server, sending
+packets to the tap port which is connected to the DHCP namespace.
+
 East-West Packet Flow
 =====================