diff --git a/doc/arch-design/ch_network_focus.xml b/doc/arch-design/ch_network_focus.xml index b3721cc94c..ce4ec79b52 100644 --- a/doc/arch-design/ch_network_focus.xml +++ b/doc/arch-design/ch_network_focus.xml @@ -37,8 +37,7 @@ 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 - network management. + NTP, or SNMP. diff --git a/doc/arch-design/network_focus/section_architecture_network_focus.xml b/doc/arch-design/network_focus/section_architecture_network_focus.xml index 5314680dd2..476defdbc1 100644 --- a/doc/arch-design/network_focus/section_architecture_network_focus.xml +++ b/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 - release, dynamic routing is currently in its infancy within OpenStack and - you may require an external device or a specialized service instance - within OpenStack to implement it. OpenStack Networking provides a - tunneling feature, however it is constrained to a Networking-managed - region. If the need arises to extend a tunnel beyond the OpenStack region - 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. + distribute workloads or offload certain functions. OpenStack Networking + provides a tunneling feature, however it is constrained to a + Networking-managed region. If the need arises to extend a tunnel beyond + the OpenStack region 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. Depending on the selected design, Networking itself might not @@ -125,10 +118,7 @@ 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 - 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 + Some workloads are possible through the use of IPv6 and IPv6 to IPv4 reverse transition mechanisms such as NAT64 and DNS64 or 6to4. This alters the requirements for any address plan as single-stacked and diff --git a/doc/arch-design/network_focus/section_user_requirements_network_focus.xml b/doc/arch-design/network_focus/section_user_requirements_network_focus.xml index 624264ebca..4078fd8c49 100644 --- a/doc/arch-design/network_focus/section_user_requirements_network_focus.xml +++ b/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. - - 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. - - Many jurisdictions have legislative and regulatory requirements - governing the storage and management of data in cloud environments. - Common areas of regulation include: - - - Data retention policies ensuring storage of persistent data - and records management to meet data archival requirements. - - - Data ownership policies governing the possession and - responsibility for data. - - - Data sovereignty policies governing the storage of data in - foreign countries or otherwise separate jurisdictions. - - - Data compliance policies govern where information can and - cannot reside in certain locations. - - - Examples of such legal frameworks include the data protection - framework of the European Union - (http://ec.europa.eu/justice/data-protection/) - and the requirements of the Financial Industry Regulatory Authority - (http://www.finra.org/Industry/Regulation/FINRARules) - in the United States. Consult a local regulatory body for more - information.
High availability issues Depending on the application and use case, network-intensive @@ -138,28 +101,4 @@
-
Security - 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: - - - Firewalls - - - Overlay interconnects for joining separated tenant networks - - - Routing through or avoiding specific networks - - - 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. -