[arch-guide] Update Network Section of Compute

New network recommendations
New interface recommendations

Change-Id: I2054d3c59cfb8edb50ce3ebe903c3a7aaa62ddbf
Implements: blueprint arch-guide-restructure

doc/arch-design-draft/source/design-compute/design-compute-networking.rst

@@ -2,15 +2,49 @@
 Network connectivity
 =====================
 
-The selected server hardware must have the appropriate number of
-network connections, as well as the right type of network
-connections, in order to support the proposed architecture. Ensure
-that, at a minimum, there are at least two diverse network
-connections coming into each rack.
+The selected server hardware must have the appropriate number of network
+connections, as well as the right type of network connections, in order to
+support the proposed architecture. Ensure that, at a minimum, there are at
+least two diverse network connections coming into each rack.
 
-The selection of form factors or architectures affects the selection of
-server hardware. Ensure that the selected server hardware is configured
-to support enough storage capacity (or storage expandability) to match
-the requirements of selected scale-out storage solution. Similarly, the
-network architecture impacts the server hardware selection and vice
-versa.
+The selection of form factors or architectures affects the selection of server
+hardware. Ensure that the selected server hardware is configured to support
+enough storage capacity (or storage expandability) to match the requirements of
+selected scale-out storage solution. Similarly, the network architecture
+impacts the server hardware selection and vice versa.
+
+While each enterprise install is different, the following networks with their
+proposed bandwidth is highly recommended for a basic production OpenStack
+install.
+
+**Install or OOB network** - Typically used by most distributions and
+provisioning tools as the network for deploying base software to the
+OpenStack compute nodes. This network should be connected at a minimum of 1Gb
+and no routing is usually needed.
+
+**Internal or Management network** - Used as the internal communication network
+between OpenStack compute and control nodes. Can also be used as a network
+for iSCSI communication between the compute and iSCSI storage nodes. Again,
+this should be a minimum of a 1Gb NIC and should be a non-routed network. This
+interface should be redundant for high availability (HA).
+
+**Tenant network** - A private network that enables communication between each
+tenant's instances. If using flat networking and provider networks, this
+network is optional. This network should also be isolated from all other
+networks for security compliance. A 1Gb interface should be sufficient and
+redundant for HA.
+
+**Storage network** - A private network which could be connected to the Ceph
+frontend or other shared storage. For HA purposes this should be a redundant
+configuration with suggested 10Gb NICs. This network isolates the storage for
+the instances away from other networks. Under load, this storage traffic
+could overwhelm other networks and cause outages on other OpenStack services.
+
+**(Optional) External or Public network** - This network is used to communicate
+externally from the VMs to the public network space. These addresses are
+typically handled by the neutron agent on the controller nodes and can also
+be handled by a SDN other than neutron. However, when using neutron DVR with
+OVS, this network must be present on the compute node since north and south
+traffic will not be handled by the controller nodes, but by the compute node
+itself. For more information on DVR with OVS and compute nodes, see `Scenario:
+High Availability using Distributed Virtual Routing (DVR) <http://docs.openstack.org/mitaka/networking-guide/scenario-dvr-ovs.html>`_