summaryrefslogtreecommitdiffstats
path: root/docs/development/scenario/scenariomatrix.rst
blob: 64e115015de1c9b0c2452a593b25500c07f38076 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
Scenarios are implemented as deployable compositions through integration with an installation tool.
OPNFV supports multiple installation tools and for any given release not all tools will support all
scenarios. While our target is to establish parity across the installation tools to ensure they
can provide all scenarios, the practical challenge of achieving that goal for any given feature and
release results in some disparity.

Brahmaputra scenario overeview
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

The following table provides an overview of the installation tools and available scenario's
in the Brahmaputra release of OPNFV.

.. image:: ../images/brahmaputrascenariomatrix.jpg
   :alt: OPNFV Brahmaputra Scenario Matrix

Scenario status is indicated by a weather pattern icon. All scenarios listed with
a weather pattern are possible to deploy and run in your environment or a Pharos lab,
however they may have known limitations or issues as indicated by the icon.

Weather pattern icon legend:

+---------------------------------------------+----------------------------------------------------------+
| Weather Icon                                | Scenario Status                                          |
+=============================================+==========================================================+
| .. image:: ../images/weather-clear.jpg      | Stable, no known issues                                  |
+---------------------------------------------+----------------------------------------------------------+
| .. image:: ../images/weather-few-clouds.jpg | Stable, documented limitations                           |
+---------------------------------------------+----------------------------------------------------------+
| .. image:: ../images/weather-overcast.jpg   | Deployable, stability or feature limitations             |
+---------------------------------------------+----------------------------------------------------------+
| .. image:: ../images/weather-dash.jpg       | Not deployed with this installer                         |
+---------------------------------------------+----------------------------------------------------------+

Scenarios that are not yet in a state of "Stable, no known issues" will continue to be stabilised
and updates will be made on the stable/brahmaputra branch. While we intend that all Brahmaputra
scenarios should be stable it is worth checking regularly to see the current status.  Due to
our dependency on upstream communities and code some issues may not be resolved prior to the C release.

Scenario Naming
^^^^^^^^^^^^^^^

In OPNFV scenarios are identified by short scenario names, these names follow a scheme that
identifies the key components and behaviours of the scenario. The rules for scenario naming are as follows:

  os-[controller]-[feature]-[mode]-[option]

Details of the fields are
  * os: mandatory

    * Refers to the platform type used
    * possible value: os (OpenStack)

* [controller]: mandatory

    * Refers to the SDN controller integrated in the platform
    * example values: nosdn, ocl, odl, onos

  * [feature]: mandatory

    * Refers to the feature projects supported by the scenario
    * example values: nofeature, kvm, ovs, sfc

  * [mode]: mandatory

    * Refers to the deployment type, which may include for instance high availability
    * possible values: ha, noha

  * [option]: optional

    * Used for the scenarios those do not fit into naming scheme.
    * The optional field in the short scenario name should not be included if there is no optional scenario.

Some examples of supported scenario names are:

  * os-nosdn-kvm-noha

    * This is an OpenStack based deployment using neutron including the OPNFV enhanced KVM hypervisor

  * os-onos-nofeature-ha

    * This is an OpenStack deployment in high availability mode including ONOS as the SDN controller

  * os-odl_l2-sfc

    * This is an OpenStack deployment using OpenDaylight and OVS enabled with SFC features

Installing your scenario
^^^^^^^^^^^^^^^^^^^^^^^^

There are two main methods of deploying your target scenario, one method is to follow this guide which will
walk you through the process of deploying to your hardware using scripts or ISO images, the other method is
to set up a Jenkins slave and connect your infrastructure to the OPNFV Jenkins master.

For the purposes of evaluation and development a number of Brahmaputra scenarios are able to be deployed
virtually to mitigate the requirements on physical infrastructure. Details and instructions on performing
virtual deployments can be found in the installer specific installation instructions.

To set up a Jenkins slave for automated deployment to your lab, refer to the `Jenkins slave connect guide.
<http://artifacts.opnfv.org/brahmaputra.1.0/docs/opnfv-jenkins-slave-connection.brahmaputra.1.0.html>`_
| to VMs; | | | |2. Must be able to support multiple L3 agents for a given |2. Yes | | | external network to support scaling (neutron scheduler | | | | to assign vRouters to the L3 agents) | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Ability for a NIC to support both IPv4 and IPv6 (dual | |Dual-stack is supported in Neutron with the addition of | |stack) address. | |``Multiple IPv6 Prefixes`` Blueprint | | | | | |1. VM with a single interface associated with a network, |1. Yes | | | which is then associated with two subnets. | | | |2. VM with two different interfaces associated with two |2. Yes | | | different networks and two different subnets. | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Support IPv6 Address assignment modes. |1. Yes | | | | | | |1. SLAAC |2. Yes | | |2. DHCPv6 Stateless | | | |3. DHCPv6 Stateful |3. Yes | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Ability to create a port on an IPv6 DHCPv6 Stateful subnet |Yes | | |and assign a specific IPv6 address to the port and have it | | | |taken out of the DHCP address pool. | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Ability to create a port with fixed_ip for a |**No** |The following patch disables this operation: | |SLAAC/DHCPv6-Stateless Subnet. | |https://review.openstack.org/#/c/129144/ | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Support for private IPv6 to external IPv6 floating IP; |**Rejected** |Blueprint proposed in upstream and got rejected. General expectation| |Ability to specify floating IPs via Neutron API (REST and | |is to avoid NAT with IPv6 by assigning GUA to tenant VMs. See | |CLI) as well as via Horizon, including combination of | |https://review.openstack.org/#/c/139731/ for discussion. | |IPv6/IPv4 and IPv4/IPv6 floating IPs if implemented. | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Provide IPv6/IPv4 feature parity in support for |**To-Do** |The L3 configuration should be transparent for the SR-IOV | |pass-through capabilities (e.g., SR-IOV). | |implementation. SR-IOV networking support introduced in Juno based | | | |on the ``sriovnicswitch`` ML2 driver is expected to work with IPv4 | | | |and IPv6 enabled VMs. We need to verify if it works or not. | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Additional IPv6 extensions, for example: IPSEC, IPv6 |**No** |It does not appear to be considered yet (lack of clear requirements)| |Anycast, Multicast | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |VM access to the meta-data server to obtain user data, SSH |**No** |This is currently not supported. Config-drive or dual-stack IPv4 / | |keys, etc. using cloud-init with IPv6 only interfaces. | |IPv6 can be used as a workaround (so that the IPv4 network is used | | | |to obtain connectivity with the metadata service) | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Full support for IPv6 matching (i.e., IPv6, ICMPv6, TCP, |Yes | | |UDP) in security groups. Ability to control and manage all | | | |IPv6 security group capabilities via Neutron/Nova API (REST| | | |and CLI) as well as via Horizon. | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |During network/subnet/router create, there should be an |Yes |Two new Subnet attributes were introduced to control IPv6 address | |option to allow user to specify the type of address | |assignment options: | |management they would like. This includes all options | | | |including those low priority if implemented (e.g., toggle | |* ``ipv6-ra-mode``: to determine who sends Router Advertisements; | |on/off router and address prefix advertisements); It must | | | |be supported via Neutron API (REST and CLI) as well as via | |* ``ipv6-address-mode``: to determine how VM obtains IPv6 address, | |Horizon | | default gateway, and/or optional information. | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Security groups anti-spoofing: Prevent VM from using a |Yes | | |source IPv6/MAC address which is not assigned to the VM | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Protect tenant and provider network from rogue RAs |Yes |When using a tenant network, Neutron is going to automatically | | | |handle the filter rules to allow connectivity of RAs to the VMs only| | | |from the Neutron router port; with provider networks, users are | | | |required to specify the LLA of the upstream router during the subnet| | | |creation, or otherwise manually edit the security-groups rules to | | | |allow incoming traffic from this specific address. | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Support the ability to assign multiple IPv6 addresses to |Yes | | |an interface; both for Neutron router interfaces and VM | | | |interfaces. | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Ability for a VM to support a mix of multiple IPv4 and IPv6|Yes | | |networks, including multiples of the same type. | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Support for IPv6 Prefix Delegation. |Yes |Partial support in Mitaka | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |Distributed Virtual Routing (DVR) support for IPv6 |**No** |Blueprint proposed upstream, pending discussion. | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |IPv6 First-Hop Security, IPv6 ND spoofing |Yes | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ |IPv6 support in Neutron Layer3 High Availability |Yes | | |(keepalived+VRRP). | | | +-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+ ****************************************** IPv6 Gap Analysis with Open Daylight Boron ****************************************** This section provides users with IPv6 gap analysis regarding feature requirement with Open Daylight Boron Official Release. The following table lists the use cases / feature requirements of VIM-agnostic IPv6 functionality, including infrastructure layer and VNF (VM) layer, and its gap analysis with Open Daylight Boron Official Release. **Open Daylight Boron Status** There are 2 options in Open Daylight Boron to provide Virtualized Networks: 1 ``Old Netvirt``: netvirt implementation used in Open Daylight Beryllium Release identified by feature ``odl-ovsdb-openstack`` 2 ``New Netvirt``: netvirt implementation which will replace the Old Netvirt in the future releases based on a more modular design. It is identified by feature ``odl-netvirt-openstack`` .. table:: :class: longtable +--------------------------------------------------+---------------------------------------------+--------------------------------------------------------------+ |Use Case / Requirement | Supported in ODL Boron |Notes | | +---------------------+-----------------------+ | | | Old Netvirt | New Netvirt | | | |(odl-ovsdb-openstack)|(odl-netvirt-openstack)| | +==================================================+=====================+=======================+==============================================================+ |REST API support for IPv6 subnet creation in ODL |Yes |Yes |Yes, it is possible to create IPv6 subnets in ODL using | | | | |Neutron REST API. | | | | | | | | | |For a network which has both IPv4 and IPv6 subnets, ODL | | | | |mechanism driver will send the port information which includes| | | | |IPv4/v6 addresses to ODL Neutron northbound API. When port | | | | |information is queried it displays IPv4 and IPv6 addresses. | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |IPv6 Router support in ODL |**No** |**Partial** |IPv6 Router support is work in progress in ODL. | | | | | | |1. Communication between VMs on same compute node | | |Currently communication between VMs on the same network is | |2. Communication between VMs on different compute | | |supported, and the support for the other modes is work in | | nodes (east-west) | | |progress. | |3. External routing (north-south) | | | | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |IPAM: Support for IPv6 Address assignment modes. |**No** |Yes |ODL IPv6 Router supports all the IPv6 Address assignment modes| | | | |along with Neutron DHCP Agent. | |1. SLAAC | | | | |2. DHCPv6 Stateless | | | | |3. DHCPv6 Stateful | | | | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |When using ODL for L2 forwarding/tunneling, it is |Yes |Yes | | |compatible with IPv6. | | | | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |Full support for IPv6 matching (i.e. IPv6, ICMPv6,|**Partial** |**Partial** |Security Groups for IPv6 is a work in progress, and some | |TCP, UDP) in security groups. Ability to control | | |partial support is available. | |and manage all IPv6 security group capabilities | | | | |via Neutron/Nova API (REST and CLI) as well as via| | | | |Horizon | | | | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |Shared Networks support |Yes |Yes | | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |IPv6 external L2 VLAN directly attached to a VM. |**ToDo** |**ToDo** | | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+ |ODL on an IPv6 only Infrastructure. |**No** |**Work in Progress** |Deploying OpenStack with ODL on an IPv6 only infrastructure | | | | |where the API endpoints are all IPv6 addresses. | +--------------------------------------------------+---------------------+-----------------------+--------------------------------------------------------------+