diff --git a/doc/openstack-ops/ch_arch_network_design.xml b/doc/openstack-ops/ch_arch_network_design.xml
index 71104ce8..6cbdbb3d 100644
--- a/doc/openstack-ops/ch_arch_network_design.xml
+++ b/doc/openstack-ops/ch_arch_network_design.xml
@@ -30,14 +30,18 @@
     <section xml:id="mgmt_network">
         <title>Management Network</title>
         <para>A management network, typically consisting of a separate
-            switch and separate NICs, is a recommended option. This
+            switch and separate NICs (Network Interface Cards), is a
+            recommended option. This
             segregation prevents system administration and monitoring
             system access from being disrupted by traffic generated by
-            the guests themselves.</para>
+            the guests.</para>
         <para>Consider creating other private networks for
             communication between internal components of OpenStack,
-            such as the Message Queue and OpenStack Compute. VLANs are
-            great for these scenarios.</para>
+            such as the Message Queue and OpenStack Compute. Using a
+            Virtual Local Area Network (VLAN)
+            works well for these scenarios because it provides
+            a method for creating multiple virtual networks on a
+            physical network.</para>
     </section>
     <section xml:id="public_addressing">
         <title>Public Addressing Options</title>
@@ -64,7 +68,8 @@
     <section xml:id="ip_address_planning">
         <title>IP Address Planning</title>
         <para>An OpenStack installation can potentially have many
-            subnets, and different types of services in each. An IP
+            subnets (ranges of IP addresses), and different types of
+            services in each. An IP
             address plan can assist with a shared understanding of
             network partition purposes and scalability. Control
             services can have public and private IP addresses, and as
@@ -75,14 +80,14 @@
         <informaltable rules="all">
             <tbody>
                 <tr>
-                    <td><para>subnet router</para></td>
+                    <td><para><emphasis role="bold">subnet router</emphasis></para></td>
                     <td><para>Packets leaving the subnet go via this
                             address, which could be a dedicated router
                             or a nova-network service.</para></td>
                 </tr>
                 <tr>
-                    <td><para>control services public
-                            interfaces</para></td>
+                    <td><para><emphasis role="bold">control services public
+                            interfaces</emphasis></para></td>
                     <td><para>Public access to
                                 <code>swift-proxy</code>,
                                 <code>nova-api</code>,
@@ -92,29 +97,29 @@
                             at individual machines.</para></td>
                 </tr>
                 <tr>
-                    <td><para>Object Storage cluster internal
-                            communications</para></td>
+                    <td><para><emphasis role="bold">Object Storage cluster internal
+                            communications</emphasis></para></td>
                     <td><para>Traffic amongst object/account/container
                             servers and between these and the proxy
                             server's internal interface uses this
                             private network.</para></td>
                 </tr>
                 <tr>
-                    <td><para>compute and storage
-                            communications</para></td>
+                    <td><para><emphasis role="bold">compute and storage
+                            communications</emphasis></para></td>
                     <td><para>If ephemeral or block storage is
                             external to the compute node, this network
                             is used.</para></td>
                 </tr>
                 <tr>
-                    <td><para>out-of-band remote
-                        management</para></td>
+                    <td><para><emphasis role="bold">out-of-band remote
+                        management</emphasis></para></td>
                     <td><para>If a dedicated remote access controller
                             chip is included in servers, often these
                             are on a separate network.</para></td>
                 </tr>
                 <tr>
-                    <td><para>in-band remote management</para></td>
+                    <td><para><emphasis role="bold">in-band remote management</emphasis></para></td>
                     <td><para>Often, an extra (such as, 1 GB)
                             interface on compute or storage nodes is
                             used for system administrators or
@@ -123,8 +128,8 @@
                             interface.</para></td>
                 </tr>
                 <tr>
-                    <td><para>spare space for future
-                        growth</para></td>
+                    <td><para><emphasis role="bold">spare space for future
+                        growth</emphasis></para></td>
                     <td><para>Adding more public-facing control
                             services, or guest instance IPs should
                             always be part of your plan.</para></td>