First overview and cleanup of network focused chapter

This is a removal of out of date information from the guide
as well as removing the sections being moved into common

Change-Id: I4dc89ddaaf6d0e2338852d37fecf61a6eeb73a30
Implements: blueprint arch-guide

doc/arch-design/ch_network_focus.xml

@@ -37,8 +37,7 @@
         <listitem>
             <para>Use this cloud to provide network service functions built to
             support the delivery of back-end network services such as DNS,
-            NTP, or SNMP. A company can use these services for internal
+            NTP, or SNMP.</para>
-            network management.</para>
         </listitem>
       </varlistentry>
       <varlistentry>

doc/arch-design/network_focus/section_architecture_network_focus.xml

@@ -31,19 +31,12 @@
       functions that it cannot provide. For many of these, you may require
       external systems or equipment to fill in the functional gaps. Hardware
       load balancers are an example of equipment that may be necessary to
-      distribute workloads or offload certain functions. As of the Icehouse
+      distribute workloads or offload certain functions. OpenStack Networking
-      release, dynamic routing is currently in its infancy within OpenStack and
+      provides a tunneling feature, however it is constrained to a
-      you may require an external device or a specialized service instance
+      Networking-managed region. If the need arises to extend a tunnel beyond
-      within OpenStack to implement it. OpenStack Networking provides a
+      the OpenStack region to either another region or an external system,
-      tunneling feature, however it is constrained to a Networking-managed
+      implement the tunnel itself outside OpenStack or use a tunnel management
-      region. If the need arises to extend a tunnel beyond the OpenStack region
+      system to map the tunnel or overlay to an external tunnel.
-      to either another region or an external system, implement the tunnel
-      itself outside OpenStack or use a tunnel management system to map the
-      tunnel or overlay to an external tunnel. OpenStack does not currently
-      provide quotas for network resources. Where network quotas are required,
-      implement quality of service management outside of OpenStack. In many of
-      these instances, similar solutions for traffic shaping or other network
-      functions are needed.
     </para>
     <para>
       Depending on the selected design, Networking itself might not
@@ -125,10 +118,7 @@
       <para>Many people overlook an important design decision: The choice of
         layer-3 protocols. While OpenStack was initially built with only IPv4
         support, Networking now supports IPv6 and dual-stacked networks.
-        As of the Icehouse release, this only includes stateless
+        Some workloads are possible through the use of IPv6 and IPv6 to IPv4
-        address auto configuration but work is in progress to support stateless
-        and stateful DHCPv6 as well as IPv6 floating IPs without NAT. Some
-        workloads are possible through the use of IPv6 and IPv6 to IPv4
         reverse transition mechanisms such as NAT64 and DNS64 or
         <glossterm>6to4</glossterm>.
         This alters the requirements for any address plan as single-stacked and

doc/arch-design/network_focus/section_user_requirements_network_focus.xml

@@ -21,44 +21,7 @@
               for the end-user, as well as productivity and economic loss.
            </para>
         </listitem>
-        <listitem>
-            <para>Regulatory requirements: Consider regulatory
-              requirements about the physical location of data as it traverses
-              the network. In addition, maintain network segregation of private
-              data flows while ensuring an encrypted network between cloud
-              locations where required. Regulatory requirements for encryption
-              and protection of data in flight affect network architectures as
-              the data moves through various networks.</para>
-        </listitem>
     </itemizedlist>
-    <para>Many jurisdictions have legislative and regulatory requirements
-      governing the storage and management of data in cloud environments.
-      Common areas of regulation include:</para>
-    <itemizedlist>
-        <listitem>
-            <para>Data retention policies ensuring storage of persistent data
-              and records management to meet data archival requirements.</para>
-        </listitem>
-        <listitem>
-            <para>Data ownership policies governing the possession and
-              responsibility for data.</para>
-        </listitem>
-        <listitem>
-            <para>Data sovereignty policies governing the storage of data in
-              foreign countries or otherwise separate jurisdictions.</para>
-        </listitem>
-        <listitem>
-            <para>Data compliance policies govern where information can and
-              cannot reside in certain locations.</para>
-        </listitem>
-    </itemizedlist>
-    <para>Examples of such legal frameworks include the data protection
-      framework of the European Union
-      (<link xlink:href="http://ec.europa.eu/justice/data-protection/">http://ec.europa.eu/justice/data-protection/</link>)
-      and the requirements of the Financial Industry Regulatory Authority
-      (<link xlink:href="http://www.finra.org/Industry/Regulation/FINRARules">http://www.finra.org/Industry/Regulation/FINRARules</link>)
-      in the United States. Consult a local regulatory body for more
-      information.</para>
     <section xml:id="high-availability-issues-network-focus">
       <title>High availability issues</title>
       <para>Depending on the application and use case, network-intensive
@@ -138,28 +101,4 @@
         </varlistentry>
       </variablelist>
     </section>
-    <section xml:id="security-network-focus"><title>Security</title>
-    <para>Users often overlook or add security after a design implementation.
-      Consider security implications and requirements before designing the
-      physical and logical network topologies. Make sure that the networks are
-      properly segregated and traffic flows are going to the correct
-      destinations without crossing through locations that are undesirable.
-      Consider the following example factors:</para>
-    <itemizedlist>
-        <listitem>
-            <para>Firewalls</para>
-        </listitem>
-        <listitem>
-            <para>Overlay interconnects for joining separated tenant networks</para>
-        </listitem>
-        <listitem>
-            <para>Routing through or avoiding specific networks</para>
-        </listitem>
-    </itemizedlist>
-    <para>How networks attach to hypervisors can expose security
-      vulnerabilities. To mitigate against exploiting hypervisor breakouts,
-      separate networks from other systems and schedule instances for the
-      network onto dedicated compute nodes. This prevents attackers
-      from having access to the networks from a compromised instance.</para>
-    </section>
 </section>