Merge "Updated ODL-L3 noha scenario doc for Danube"

5 files changed, 128 insertions, 117 deletions

diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png b/docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png
new file mode 100755
index 0000000..27c8335
--- /dev/null
+++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-L3-noha-sample-setup.png
diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg b/docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg
new file mode 100755
index 0000000..e92851f
--- /dev/null
+++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-basic-components.jpg
diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png b/docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png
new file mode 100755
index 0000000..1193ea4
--- /dev/null
+++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-odl_l3-noha-overview.png
diff --git a/docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png b/docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png
new file mode 100755
index 0000000..04546aa
--- /dev/null
+++ b/docs/scenarios/os-odl_l3-fdio-noha/FDS-simple-callflow.png
diff --git a/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst b/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst
index bf32eb6..6bbf12b 100755
--- a/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst
+++ b/docs/scenarios/os-odl_l3-fdio-noha/scenario.description.rst
@@ -40,8 +40,8 @@ NFV infrastructure are
     reflect different business
 
 In order to meet the desired qualities of an NFV infrastructure, the
-following components were chosen for the "Openstack - OpenDaylight
- - FD.io/VPP" scenario:
+following components were chosen for the "Openstack - OpenDaylight - FD.io"
+scenario:
   * FD.io Vector Packet Processor (VPP) - a highly scalable,
     high performance, extensible virtual forwarder
   * OpenDaylight Controller - an extensible controller platform which
@@ -52,7 +52,7 @@ following components were chosen for the "Openstack - OpenDaylight
     deployment.
 
 
-The "Openstack - OpenDaylight - FD.io/VPP" scenario provides the capability to
+The "Openstack - OpenDaylight - FD.io" scenario provides the capability to
 realize a set of use-cases relevant to the deployment of NFV nodes instantiated
 by means of an Openstack orchestration system on FD.io/VPP enabled compute
 nodes. The role of the Opendaylight network controller in this integration is
@@ -74,22 +74,30 @@ servers:
   * 1 Jumphost hosting the APEX installer - running the Undercloud
   * 1 Controlhost, which runs the Overcloud as well as
       OpenDaylight as a network controller
-  * 2 or more Computehosts
-
-.. image:: FDS-odl_l3-overview.png
-
-Tenant and public networking leverages FD.io/VPP. VPP binds to both, the tenant
-networking interface as well as to the public networking interface on the
-compute and control nodes. The OpenDaylight network controller is used to setup
-and manage layer 2 and layer 3 networking for the scenario - with Group Based
-Policy (GBP) being the key component. Tenant networking can either leverage
-VXLAN (in which case a full mesh of VXLAN tunnels is created) or VLANs. Layer 3
-connectivity is provided by using VPP as a "distributed virtual router".
-
-The picture below gives an example for distributed routing using VRFs between
-tenant networks.
-
-.. image:: FDS-L3-DVR-example.png
+  * 2 or more Computehosts. One of the Computehosts also serves as
+      layer 3 gateway for the tenant networks.
+
+.. image:: FDS-odl_l3-noha-overview.png
+
+Tenant and public networking leverages FD.io/VPP. On one of the compute nodes,
+VPP binds to both, the tenant networking interface as well as to the public
+networking interface. This means that VPP is used for communication within
+a tenant network, between tenant networks, as well as between a tenant network
+and the Internet. Note that this setup slightly differs from the usual
+centralized L3 setup with qrouter on the control node. This setup was chosen
+to limit the configuration changes for the introduction of FD.io/VPP.  The
+OpenDaylight network controller is used to setup and manage layer 2 and
+layer 3 networking for the scenario - with Group Based Policy (GBP) being the
+key component. Tenant networking can either leverage VXLAN (in which case a
+full mesh of VXLAN tunnels is created) or VLANs.
+
+The picture below shows an example setup with two compute and one control
+node. Note that the external network is connected via compute node 0 through
+VPP. VPP provides all layer 3 services which are provided in a "vanilla"
+OpenStack deployment, including SNAT and DNAT, as well as north-south
+and east-west traffic filtering for security purposes ("security groups").
+
+.. image:: FDS-L3-noha-sample-setup.png
 
 Features of the scenario
 ------------------------
@@ -100,7 +108,7 @@ Main features of the "apex-os-odl_l3-fdio-noha" scenario:
   * Fast and scalable tenant networking using FD.io/VPP as forwarder
   * Layer 2 networking using VLANs or VXLAN, managed
     and controlled through OpenDaylight
-  * Layer 3 connectivitiy for tenant networks supplied in a distributed way
+  * Layer 3 connectivitiy for tenant networks supplied
     through FD.io/VPP. Layer 3 features, including security groups as well as
     floating IP addresses (i.e. NAT) are implemented by the FD.io/VPP forwarder
   * Manual and automatic (via DHCP) addressing on tenant networks
@@ -122,86 +130,39 @@ and the Layer 3 scenario "apex-os-odl_l3-fdio-noha" share the same components.
 
 Here's a more detailed list of the individual software components involved:
 
-**Openstack Neutron ML2 ODL Plugin**: Handles Neutron data base synchronization
-and interaction with the southbound Openstack controller using HTTP.
-
-**OpenDaylight Neutron Nothbound & Neutron MD-SAL Entry Store**: Presents a
-Neutron (v2) extended HTTP API servlet for interaction with Openstack Neutron.
-It validates and stores the received Neutron data in the MD-SAL data store
-against the Neutron yang model driven.
-
-**OpenDaylight Neutron Mapper**: The Neutron Mapper listens to Neutron data
-change events and is responsible for using Neutron data in creating Group Based
-Policy Data objects, e.g. GBP End-Points, Flood-Domains. A GBP End Point
-represents a specific NFV/VM port and its identity as derived from a Neutron
-Port. The mapped data is stored using the GBP End Point yang model and an
-association between the GBP End-Point and its Neutron object is maintained in
-the Neutron-GBP map.
-
-**OpenDaylight Group Based Policy (GBP) Entities store**: Stores for the GBP
-data artifacts against the GBP YANG schemas.
-
-**Neutron Group Based Policy Map store**: Stores the bi-lateral relation
-between an End-Point and its corresponding Neutron object. Neutron-GBP map;
-keyed by Neutron object type, port, and Neutron UUID, gives the GBP End-Point,
-Flood domain respectively. GBP-Neutron map keyed by GBP object type, end-point.
-
-**Neutron VPP Renderer Mapper**: The Neutron VPP Renderer Mapper listens to
-Neutron Store data change events, as well as being able to access directly the
-store, and is responsible for converting Neutron data specifically required to
-render a  VPP node configuration with a given End Point, e.g. the virtual host
-interface name assigned to a vhostuser socket.. The mapped data is stored in
-the VPP info data store.
-
-**VPP Info Store**: Stores VPP specific information regarding End-Points, Flood
-domains with VLAN, etc.
-
-**GBP Renderer Manager**: The GBP Renderer Manager is the central point for
-dispatching of data to specific device renderers.  It uses the information
-derived from the GBP end-point and its topology entries to dispatch the task of
-configuration to a specific device renderer by writing a renderer policy
-configuration into the registered renderer's policy store. The renderer manager
-also monitors, by being a data change listener on the VPP Renderer Policy
-States, for any errors in the application of a rendered configuration.
-
-**Renderer Policy Config Store**: The store's schema serves as the API between
-the Renderer Manager and specific Renderers like the VPP Renderer. The store
-uses a a YANG modeled schema to represent all end-point and associated GBP
-policy data.
-
-**Topology Entries Store**: The yang model based MD-SAL topology store serves
-two fundamental roles: 1. It maintains a topological representation of the GBP
-End Points, in the context of customer networks. 2. It maintains an association
-of each (VPP) compute node's physical interfaces to their neutron provider
-network (e.g. The association between an ethernet interface and a Neutron
-provider network).
-
-**VPP Renderer**: The VPP Renderer registers an instance for VPP nodes with the
-Renderer Manager by means of inserting operational data into the Renderer
-Policy config store. It acts as a listener on the Renderer Policy consumes via
-the GBP Policy API data + the specific VPP End Point data, to drive the
-configuration of VPP devices using NETCONF Services.
-More specifically, the renderer generates:
-
-  * vhost user port configuration that corresponds to the VM port configuration
-  * VPP bridge instances corresponding to the GBP flood domain
-  * port or traffic filtering configuration, in accordance with the GBP policy.
-
-The VPP Renderer also interacts with the Virtual Bridge Domain Service, by
-means of the VBD store, in order to establish connectivity between VPP nodes in
-a bridge domain. For this it uses the VPP device name, and the flood domain
-data derived from the VPP Info and End-Point data respectively.  For the
-executed configuration operations it updates state in the Renderer policy state
-store.
-
-**Virtual Bridge Domain (VBD) Store and Manager**: The virtual bridge domain
-manager is responsible for configuring the VxLAN overlay tunnel infrastructure
-to arrive at a desired bridged topology between multiple (VPP) compute nodes.
-VDB configures VXLAN tunnels always into a full-mesh with split-horizon group forwarding applied on any domain facing tunnel interface (i.e. forwarding behavior will be that used for VPLS).
-
-**NETCONF Mount Point Service & Connector**: Collectively referred to as
-Netconf Services, provide the NETCONF interface for accessing VPP configuration
-and operational data stores that are represented as NETCONF mounts.
+**Openstack Neutron ML2 OpenDaylight Plugin**: Handles Neutron data base
+synchronization and interaction with the southbound controller using a REST
+interface.
+
+**ODL GBP Neutron Mapper**: Maps neutron elements like networks, subnets,
+security groups, etc. to GBP entities: Creates policy and configuration for
+tenants (endpoints, resolved policies, forwarding rules).
+
+**ODL GBP Neutron VPP Mapper**: Maps Neutron ports to VPP endpoints in GBP.
+
+**ODL GBP Location Manager**: Provides real location for endpoints (i.e. Which
+physical node an endpoint is connected to).
+
+**GBP Renderer Manager**: Creates configuration for Renderers (like e.g.
+VPP-Renderer or OVS-Renderer). The GBP Renderer Manager is the central point
+for dispatching of data to specific device renderers.  It uses the information
+derived from the GBP end-point and its topology entries to dispatch the task
+of configuration to a specific device renderer by writing a renderer policy
+configuration into the registered renderer's policy store. The renderer
+manager also monitors, by being a data change listener on the VPP Renderer
+Policy States, for any errors in the application of a rendered configuration.
+
+**GBP VPP Renderer Interface Manager**: Listens to VPP endpoints in the
+Config DataStore and configures associated interfaces on VPP via HoneyComb.
+
+**GBP VPP Renderer Renderer Policy Manager**: Manages the creation of
+bridge domains using VBD and assigns interfaces to bridge domains.
+
+**Virtual Bridge Domain Manager (VBD)**: Creates bridge domains (i.e. in case
+of VXLAN creates full mesh of VXLAN tunnels, configures split horizon on
+tunnel endpoints etc.). VDB configures VXLAN tunnels always into a full-mesh
+with split-horizon group forwarding applied on any domain facing tunnel
+interface (i.e. forwarding behavior will be that used for VPLS).
 
 **Virtual Packet Processor (VPP) and Honeycomb server**: The VPP is the
 accelerated data plane forwarding engine relying on vhost user interfaces
@@ -209,20 +170,44 @@ towards Virtual Machines created by the Nova Agent. The Honeycomb NETCONF
 configuration server is responsible for driving the configuration of the VPP,
 and collecting the operational data.
 
-**Rendered Policy State Store**: Stores data regarding the execution of
-operations performed by a given renderer.
-
 **Nova Agent**: The Nova Agent, a sub-component of the overall Openstack
 architecture, is responsible for interacting with the compute node's host
 Libvirt API to drive the life-cycle of Virtual Machines. It, along with the
 compute node software, are assumed to be capable of supporting vhost user
 interfaces.
 
-The picture below show a basic end to end call flow for creating a Neutron
-vhostuser port on VPP using a GBP renderer. It showcases how the different
-component described above interact.
-
-.. image:: FDS-basic-callflow.jpg
+The picture below shows the key components.
+
+.. image:: FDS-basic-components.jpg
+
+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:
+
+To create or update a port, Neutron will send a request to ODL Neutron
+Northbound which contains the UUID, along with the host-id as "vpp" and
+vif-type as "vhost-user". The GBP Neutron mapper turns the "Neutron speak" of
+"ports" into the generic connectivity model that GroupBasedPolicy uses.
+Neutron "ports" become generic "GBP Endpoints" which can be consumed by the
+GBP Renderer Manager. The GBP Renderer Manager resolves the policy for the
+endpoint, i.e. it determines which communication relationships apply to the
+specific endpoint, and hands the resolution to a device specific renderer,
+which is the VPP renderer in the given case here. VPP renderer turns the
+generic policy into VPP specific configuration. Note that in case the policy
+would need to be applied to a different device, e.g. an OpenVSwitch (OVS),
+then an "OVS Renderer" would be used. VPP Renderer and the topology manager
+("Virtual Bridge Domain" manager - i.e. VBD) cooperate to create the actual
+network configuration. VPP Renderer configures the interfaces to the virtual
+machines (VM), i.e. the vhost-user interface in the given case here and
+attaches them to a bridge domain on VPP. VBD handles the setup of connectivity
+between bridge domains on individual VPPs, i.e. it maintains the VXLAN tunnels
+in the given case here. Both VPP Renderer as well as VBD communicate with the
+device through Netconf/YANG. All compute and control nodes run an instance of
+VPP and the VPP-configuration agent "Honeycomb". Honeycomb serves as a
+Netconf/YANG server, receives the configuration commands from VBD and VPP
+Renderer and drives VPP configuration using VPP's local Java APIs.
+
+.. image:: FDS-simple-callflow.png
 
 Scenario Configuration
 ======================
@@ -232,25 +217,51 @@ settings in the APEX configuration files. Those are typically found in
 /etc/opnfv-apex.
 
 File "deploy_settings.yaml": Choose Opendaylight as controller with version
-"boron" and enable vpp as forwarder::
-
-  global_params:
-    ha_enabled: false
+"carbon" and enable vpp as forwarder. "odl_routing_node" chooses the node
+which is used as the layer 3 gateway for the tenant networks.
+"odl_routing_node" is an optional parameter. If omitted, the VPP on the first
+compute node will serve as layer 3 gateway::
 
   deploy_options:
     sdn_controller: opendaylight
     sdn_l3: true
-    odl_version: boron
-    tacker: false
-    congress: false
+    odl_version: carbon
+    odl_routing_node: overcloud-novacompute-0
+    tacker: true
+    congress: true
     sfc: false
     vpn: false
     vpp: true
+    dataplane: fdio
+    performance:
+      Controller:
+        kernel:
+          hugepages: 1024
+          hugepagesz: 2M
+          intel_iommu: 'on'
+          iommu: pt
+          isolcpus: 1,2
+        vpp:
+          main-core: 1
+          corelist-workers: 2
+          uio-driver: uio_pci_generic
+      Compute:
+        kernel:
+          hugepagesz: 2M
+          hugepages: 2048
+          intel_iommu: 'on'
+          iommu: pt
+          isolcpus: 1,2
+        vpp:
+          main-core: 1
+          corelist-workers: 2
+          uio-driver: uio_pci_generic
 
 Limitations, Issues and Workarounds
 ===================================
 
-There are no known issues.
+For specific information on limitations and issues, please refer to the APEX
+installer release notes.
 
 References
 ==========
@@ -260,4 +271,4 @@ References
   * Fast Data (FD.io): https://fd.io/
   * FD.io Vector Packet Processor (VPP): https://wiki.fd.io/view/VPP
   * OpenDaylight Controller: https://www.opendaylight.org/
-  * OPNFV Colorado release - more information: http://www.opnfv.org/colorado
+  * OPNFV Danube release - more information: http://www.opnfv.org/danube