summaryrefslogtreecommitdiffstats
path: root/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
diff options
context:
space:
mode:
authorChristopherPrice <christopher.price@ericsson.com>2017-04-26 15:25:55 +0200
committerChristopher Price <christopher.price@ericsson.com>2017-04-27 10:04:23 +0000
commitb8722fae5e61ca71a43f3d69d1d093906b140bbe (patch)
tree40584e9f72f3b38cd98f3064df0d6b5a476dfa7a /docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
parentacee332cda9fab1315ee1147ab12bc4003f05990 (diff)
Setting the document directory structure according to the Plugfest outcome.
Implemented a directory and file structure that supports the requirements defined in the plugfest etherpad: https://etherpad.opnfv.org/p/cvp_tooling_sketch Change-Id: Icb7d2db4b0132f2039c680883e173ff5d7fc0120 Signed-off-by: ChristopherPrice <christopher.price@ericsson.com>
Diffstat (limited to 'docs/testing/user/testspecification/old_files/ipv6/designspecification.rst')
-rw-r--r--docs/testing/user/testspecification/old_files/ipv6/designspecification.rst133
1 files changed, 133 insertions, 0 deletions
diff --git a/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst b/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
new file mode 100644
index 00000000..9e403472
--- /dev/null
+++ b/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
@@ -0,0 +1,133 @@
+.. This work is licensed under a Creative Commons Attribution 4.0 International License.
+.. http://creativecommons.org/licenses/by/4.0
+.. (c) Christopher Price (Ericsson AB) and others
+
+==============================
+IPv6 test design specification
+==============================
+
+This document outlines the approach and method for testing IPv6 in the OPNFV compliance test
+suite. Providing a brief outline of the features to be tested, the methodology for testing,
+schema's and criteria.
+
+Features to be tested
+=====================
+
+The IPv6 compliance test plan outlines the method for testing IPv6 compliance to the OPNFV
+platform behaviours and features of IPv6 enabled VNFi platforms. The specific features to
+be tested by the IPv6 compliance test suite is outlined in the following table.
+
+.. table::
+ :class: longtable
+
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Features / Requirements |Tests available | Test Cases |
++===========================================================+===================+====================================================================+
+|All topologies work in a multi-tenant environment |No | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|IPv6 VM to VM only |No | |
+| | | |
+| | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|IPv6 external L2 VLAN directly attached to a VM |No | |
+| | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|IPv6 subnet routed via L3 agent to an external IPv6 network|No | |
+| | | |
+|1. Both VLAN and overlay (e.g. GRE, VXLAN) subnet attached | | |
+| to VMs; | | |
+|2. Must be able to support multiple L3 agents for a given | | |
+| 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 |No | |
+|stack) address. | | |
+| | | |
+|1. VM with a single interface associated with a network, | | |
+| which is then associated with two subnets. | | |
+|2. VM with two different interfaces associated with two | | |
+| different networks and two different subnets. | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Support IPv6 Address assignment modes. |No | |
+| | | |
+|1. SLAAC | | |
+|2. DHCPv6 Stateless | | |
+|3. DHCPv6 Stateful | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Ability to create a port on an IPv6 DHCPv6 Stateful subnet |No | |
+|and assign a specific IPv6 address to the port and have it | | |
+|taken out of the DHCP address pool. | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Full support for IPv6 matching (i.e., IPv6, ICMPv6, TCP, |No | |
+|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 |No | |
+|option to allow user to specify the type of address | | |
+|management they would like. This includes all options | | |
+|including those low priority if implemented (e.g., toggle | | |
+|on/off router and address prefix advertisements); It must | | |
+|be supported via Neutron API (REST and CLI) as well as via | | |
+|Horizon | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Security groups anti-spoofing: Prevent VM from using a |No | |
+|source IPv6/MAC address which is not assigned to the VM | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Protect tenant and provider network from rogue RAs |No | |
+| | | |
+| | | |
+| | | |
+| | | |
+| | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Support the ability to assign multiple IPv6 addresses to |No | |
+|an interface; both for Neutron router interfaces and VM | | |
+|interfaces. | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Ability for a VM to support a mix of multiple IPv4 and IPv6|No | |
+|networks, including multiples of the same type. | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|Support for IPv6 Prefix Delegation. |No | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|IPv6 First-Hop Security, IPv6 ND spoofing |No | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+|IPv6 support in Neutron Layer3 High Availability |No | |
+|(keepalived+VRRP). | | |
++-----------------------------------------------------------+-------------------+--------------------------------------------------------------------+
+
+
+Test approach for IPv6
+======================
+
+The most common approach for testing IPv6 capabilities in the test suite is through interaction with the SUT control plane.
+In this instance the test framework will exercise the NBI provided by the VIM to configure and leverage IPv6 related features
+in the platform, instantiate workloads, and invoke behaviours in the platform. The suite may also interact directly with the
+data plane to exercise platform capabilities and further invoke helper functions on the platform for the same purpose.
+
+Test result analysis
+--------------------
+
+All functional tests in the IPv6 test suite will provide a pass/fail result on completion of the test. In addition test logs
+and relevant additional information will be provided as part of the test log, available on test suite completion.
+
+Some tests in the compliance suite measure such metrics as latency and performance. At this time these tests are intended to
+provide a feature based pass/fail metric not related to system performance.
+These tests may however provide detailed results of performance and latency in the 'test report'_ document.
+
+Test identification
+===================
+
+TBD: WE need to identify the test naming scheme we will use in DoveTail in order that we can cross reference to the test
+projects and maintain our suite effectively. This naming scheme needs to be externally relevant to non-OPNFV consumers and as
+such some consideration is required on the selection.
+
+Pass Fail Criteria
+==================
+
+This section requires some further work with the test teams to identify how and where we generate, store and provide results.