diff options
Diffstat (limited to 'docs')
| -rw-r--r-- | docs/requirements/conf.py | 55 | ||||
| -rw-r--r-- | docs/requirements/glossary.rst | 3 | ||||
| -rw-r--r-- | docs/requirements/index.rst | 4 | ||||
| -rw-r--r-- | docs/requirements/references.rst | 4 | ||||
| -rw-r--r-- | docs/requirements/use_cases/georedundancy_cells.rst | 2 | ||||
| -rw-r--r-- | docs/requirements/use_cases/georedundancy_regions_insances.rst | 2 | ||||
| -rw-r--r-- | docs/requirements/use_cases/l3vpn_ecmp.rst | 10 | ||||
| -rw-r--r-- | docs/requirements/use_cases/l3vpn_hub_and_spoke.rst | 95 | ||||
| -rw-r--r-- | docs/requirements/use_cases/multiple_backends.rst | 17 |
9 files changed, 125 insertions, 67 deletions
diff --git a/docs/requirements/conf.py b/docs/requirements/conf.py new file mode 100644 index 0000000..9912324 --- /dev/null +++ b/docs/requirements/conf.py @@ -0,0 +1,55 @@ +# Copyright 2016 Open Platform for NFV Project, Inc. and its contributors +# +# Licensed under the Apache License, Version 2.0 (the "License"); +# you may not use this file except in compliance with the License. +# You may obtain a copy of the License at +# +# http://www.apache.org/licenses/LICENSE-2.0 +# +# Unless required by applicable law or agreed to in writing, software +# distributed under the License is distributed on an "AS IS" BASIS, +# WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. +# See the License for the specific language governing permissions and +# limitations under the License. +# +# What this is: Configuration file for OPNFV NetReady requirements +# documentation based on the configuration file used by the Copper project. +# + +import datetime +import sys +import os +import subprocess + +try: + __import__('imp').find_module('sphinx.ext.numfig') + extensions = ['sphinx.ext.numfig'] +except ImportError: + # 'pip install sphinx_numfig' + extensions = ['sphinx_numfig'] + +try: + __import__('imp').find_module('sphinxcontrib-fulltoc') +except ImportError: + subprocess.call("pip install sphinxcontrib-fulltoc", shell=True) +extensions.append('sphinxcontrib-fulltoc') + +# numfig: +number_figures = True +figure_caption_prefix = "Fig." + +source_suffix = '.rst' +master_doc = 'index' +pygments_style = 'sphinx' +html_use_index = True +html_theme = 'sphinx_rtd_theme' + +pdf_documents = [('index', u'OPNFV', u'OPNFV NetReady Project', u'OPNFV')] +pdf_fit_mode = "shrink" +pdf_stylesheets = ['sphinx','kerning','a4'] +#latex_domain_indices = False +#latex_use_modindex = False + +latex_elements = { + 'printindex': '', +} diff --git a/docs/requirements/glossary.rst b/docs/requirements/glossary.rst index fb7f7e7..f6d55cd 100644 --- a/docs/requirements/glossary.rst +++ b/docs/requirements/glossary.rst @@ -1,7 +1,8 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -**Definition of terms** +Definition of terms +=================== Different standards developing organizations and communities use different terminology related to Network Function Virtualization, Cloud Computing, and diff --git a/docs/requirements/index.rst b/docs/requirements/index.rst index 21147bd..6c4516f 100644 --- a/docs/requirements/index.rst +++ b/docs/requirements/index.rst @@ -41,9 +41,6 @@ NetReady: Network Readiness \newpage -.. include:: - glossary.rst - .. toctree:: :maxdepth: 4 :numbered: @@ -52,4 +49,5 @@ NetReady: Network Readiness use_cases.rst retired_use_cases.rst summary.rst + glossary.rst references.rst diff --git a/docs/requirements/references.rst b/docs/requirements/references.rst index 5f1f925..76cb5bf 100644 --- a/docs/requirements/references.rst +++ b/docs/requirements/references.rst @@ -1,8 +1,8 @@ .. This work is licensed under a Creative Commons Attribution 4.0 International License. .. http://creativecommons.org/licenses/by/4.0 -.. References -.. ========== +References +========== .. [BGPVPN] http://docs.openstack.org/developer/networking-bgpvpn/ .. [MULTISITE] https://wiki.opnfv.org/display/multisite/Multisite diff --git a/docs/requirements/use_cases/georedundancy_cells.rst b/docs/requirements/use_cases/georedundancy_cells.rst index e1673a6..a4d1f0c 100644 --- a/docs/requirements/use_cases/georedundancy_cells.rst +++ b/docs/requirements/use_cases/georedundancy_cells.rst @@ -46,7 +46,7 @@ Dependencies on compute services Data model objects ++++++++++++++++++ - local and remote endpoint objects (Most probably IP addresses with some - additional properties). + additional properties). Current implementation ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/requirements/use_cases/georedundancy_regions_insances.rst b/docs/requirements/use_cases/georedundancy_regions_insances.rst index e3faf2d..c2550eb 100644 --- a/docs/requirements/use_cases/georedundancy_regions_insances.rst +++ b/docs/requirements/use_cases/georedundancy_regions_insances.rst @@ -39,7 +39,7 @@ Northbound API / Workflow Data model objects ++++++++++++++++++ - local and remote endpoint objects (Most probably IP addresses with some -additional properties). + additional properties). Current implementation ~~~~~~~~~~~~~~~~~~~~~~ diff --git a/docs/requirements/use_cases/l3vpn_ecmp.rst b/docs/requirements/use_cases/l3vpn_ecmp.rst index 7bcb64f..93f5234 100644 --- a/docs/requirements/use_cases/l3vpn_ecmp.rst +++ b/docs/requirements/use_cases/l3vpn_ecmp.rst @@ -135,14 +135,14 @@ Gaps in the current solution Given the use case description and the currently available implementation in OpenStack provided by BGPVPN project, we identify the following gaps: -* [L3VPN-ECMP-GAP1] Static routes are not yet supported by the BGPVPN project. +* **[L3VPN-ECMP-GAP1] Static routes are not yet supported by the BGPVPN project.** Currently, no API for configuring static routes is available in the BGPVPN project. This feature is on the road map, however. -* [L3VPN-ECMP-GAP2] Behavior not defined for multiple Neutron ports of the same - IP +* **[L3VPN-ECMP-GAP2] Behavior not defined for multiple Neutron ports of the same + IP** The Neutron and BGPVPN API allow for creating multiple ports with the same IP in different networks and associating the networks with the same VPN. The @@ -151,8 +151,8 @@ OpenStack provided by BGPVPN project, we identify the following gaps: of this feature is on the road map of the project, however. -* [L3VPN-ECMP-GAP3] It is not possible to assign the same IP to multiple Neutron - ports within the same Neutron subnet. +* **[L3VPN-ECMP-GAP3] It is not possible to assign the same IP to multiple Neutron + ports within the same Neutron subnet.** This is due to the fundamental requirement of avoiding IP collisions within the L2 domain which is a Neutron network. diff --git a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst index ca58f67..e98bd25 100644 --- a/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst +++ b/docs/requirements/use_cases/l3vpn_hub_and_spoke.rst @@ -108,20 +108,24 @@ by creating a dedicated Neutron network with two subnets for each VRF in the Hub-and-Spoke topology. 1. Create Neutron network "hub" + ``neutron net-create --tenant-id Blue hub`` 2. Create a separate Neutron network for every "spoke" + ``neutron net-create --tenant-id Blue spoke-i`` 3. For every network (hub and spokes), create two subnets + ``neutron subnet-create <hub/spoke-i UUID> --tenant-id Blue 10.1.1.0/24`` ``neutron subnet-create <hub/spoke-i UUID> --tenant-id Blue 10.3.7.0/24`` 4. Create the Neutron ports in the corresponding networks + ``neutron port-create --tenant-id Blue --name vFW(H) --fixed-ip subnet_id=<hub UUID>,ip_address=10.1.1.5`` ``neutron port-create --tenant-id Blue --name VNF1(S) --fixed-ip subnet_id=<spoke-i UUID>,ip_address=10.3.7.9`` @@ -133,19 +137,23 @@ Hub-and-Spoke topology. 5. Create a BGPVPN object (VRF) for the hub network with the corresponding import and export targets + ``neutron bgpvpn-create --name hub-vrf --import-targets <RT-hub RT-spoke> --export-targets <RT-hub>`` 6. Create a BGPVPN object (VRF) for every spoke network with the corresponding import and export targets + ``neutron bgpvpn-create --name spoke-i-vrf --import-targets <RT-hub> --export-targets <RT-spoke>`` 7. Associate the hub network with the hub VRF + ``bgpvpn-net-assoc-create hub --network <hub network-UUID>`` 8. Associate each spoke network with the corresponding spoke VRF + ``bgpvpn-net-assoc-create spoke-i --network <spoke-i network-UUID>`` @@ -191,64 +199,61 @@ OpenStack provided by [BGPVPN]_ project and [NETWORKING-SFC]_ project, we identify the following gaps: -[L3VPN-HS-GAP1] No means to disable layer 2 semantic of Neutron networks -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' +* **[L3VPN-HS-GAP1] No means to disable layer 2 semantic of Neutron networks** -Neutron networks were originally designed to represent layer 2 broadcast -domains. As such, all ports connected to a network are in principle -inter-connected on layer 2 (not considering security rules here). In contrast, -in order to realize L3VPN use cases such as the hub-and-spoke topology, -connectivity among ports must be controllable on a per port basis on layer 3. + Neutron networks were originally designed to represent layer 2 broadcast + domains. As such, all ports connected to a network are in principle + inter-connected on layer 2 (not considering security rules here). In contrast, + in order to realize L3VPN use cases such as the hub-and-spoke topology, + connectivity among ports must be controllable on a per port basis on layer 3. -There are ongoing efforts to relax this design assumption, for instance by means -of routed networks ([NEUTRON-ROUTED-NETWORKS]_). In a routed network, a Neutron network -is a layer 3 domain which is composed of multiple layer 2 segments. A routed -network only provides layer 3 connectivity across segments, but layer 2 -connectivity across segments is **optional**. This means, depending on the -particular networking backend and segmentation technique used, there might be -layer 2 connectivity across segments or not. A new flag ``l2_adjacency`` -indicates whether or not a user can expect layer 2 connectivity or not across -segments. + There are ongoing efforts to relax this design assumption, for instance by means + of routed networks ([NEUTRON-ROUTED-NETWORKS]_). In a routed network, a Neutron network + is a layer 3 domain which is composed of multiple layer 2 segments. A routed + network only provides layer 3 connectivity across segments, but layer 2 + connectivity across segments is **optional**. This means, depending on the + particular networking backend and segmentation technique used, there might be + layer 2 connectivity across segments or not. A new flag ``l2_adjacency`` + indicates whether or not a user can expect layer 2 connectivity or not across + segments. -This flag, however, is ready-only and cannot be used to overwrite or disable the -layer 2 semantics of a Neutron network. + This flag, however, is ready-only and cannot be used to overwrite or disable the + layer 2 semantics of a Neutron network. -[L3VPN-HS-GAP2] No port-association available in the BGPVPN project yet -''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' +* **[L3VPN-HS-GAP2] No port-association available in the BGPVPN project yet** -Due to gap [L3VPN-HS-GAP1], the [BGPVPN]_ project was not yet able to implement -the concept of a port association. A port association would allow to associate -individual ports with VRFs and thereby control layer 3 connectivity on a per -port basis. + Due to gap [L3VPN-HS-GAP1], the [BGPVPN]_ project was not yet able to implement + the concept of a port association. A port association would allow to associate + individual ports with VRFs and thereby control layer 3 connectivity on a per + port basis. -The workflow described above intents to mimic port associations by means of -separate Neutron networks. Hence, the resulting workflow is overly complicated -and not intuitive by requiring to create additional Neutron entities (networks) -which are not present in the target topology. Moreover, creating large numbers -of Neutron networks limits scalability. + The workflow described above intents to mimic port associations by means of + separate Neutron networks. Hence, the resulting workflow is overly complicated + and not intuitive by requiring to create additional Neutron entities (networks) + which are not present in the target topology. Moreover, creating large numbers + of Neutron networks limits scalability. -Port associations are on the road map of the [BGPVPN]_ project, however, no -design that overcomes the problems outlined above has been specified yet. -Consequently, the time-line for this feature is unknown. + Port associations are on the road map of the [BGPVPN]_ project, however, no + design that overcomes the problems outlined above has been specified yet. + Consequently, the time-line for this feature is unknown. -As a result, creating a clean Hub-and-Spoke topology is current not yet -supported by the [BGPVPN]_ API. + As a result, creating a clean Hub-and-Spoke topology is current not yet + supported by the [BGPVPN]_ API. -[L3VPN-HS-GAP3] No support for static routes in the BGPVPN project yet -'''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''' +* **[L3VPN-HS-GAP3] No support for static routes in the BGPVPN project yet** -In order to realize the hub-and-spoke use case, a static route is needed to -attract the traffic at the hub to the corresponding VNF (direct traffic to the -firewall). Support for static routes in the BGPVPN project is available for the -router association by means of the Neutron router extra routes feature. However, -there is no support for static routes for network and port associations yet. + In order to realize the hub-and-spoke use case, a static route is needed to + attract the traffic at the hub to the corresponding VNF (direct traffic to the + firewall). Support for static routes in the BGPVPN project is available for the + router association by means of the Neutron router extra routes feature. However, + there is no support for static routes for network and port associations yet. -Design work for supporting static routes for network associations has started, -but no final design has been proposed yet. + Design work for supporting static routes for network associations has started, + but no final design has been proposed yet. .. -.. [L3VPN-HS-GAP4] Creating a clean hub-and-spoke topology is current not yet supported by the NETWORKING-SFC API. +.. L3VPN-HS-GAP4 Creating a clean hub-and-spoke topology is current not yet supported by the NETWORKING-SFC API. .. [Georg: We need to look deeper into SFC before we can substantiate our claim] - +.. diff --git a/docs/requirements/use_cases/multiple_backends.rst b/docs/requirements/use_cases/multiple_backends.rst index 2aefe8a..a31d1ab 100644 --- a/docs/requirements/use_cases/multiple_backends.rst +++ b/docs/requirements/use_cases/multiple_backends.rst @@ -117,17 +117,16 @@ Given the use case description and the current implementation of OpenStack Neutron, we identify the following gaps: -[MB-GAP1] Limited support for multiple back-ends -''''''''''''''''''''''''''''''''''''''''''''''' +* **[MB-GAP1] Limited support for multiple back-ends** -As pointed out above, the Neutron core plugin mechanism only allows for one -active plugin at a time. The ML2 plugin allows for running multiple mechanism -drivers in parallel, however, successful inter-working strongly depends on the -individual driver. + As pointed out above, the Neutron core plugin mechanism only allows for one + active plugin at a time. The ML2 plugin allows for running multiple mechanism + drivers in parallel, however, successful inter-working strongly depends on the + individual driver. -Moreover, the ML2 plugin and its API is - by design - very layer 2 focused. For -NFV networking use cases beyond layer 2, for instance L3VPNs, a more flexible -API is required. + Moreover, the ML2 plugin and its API is - by design - very layer 2 focused. For + NFV networking use cases beyond layer 2, for instance L3VPNs, a more flexible + API is required. Conclusion |