summaryrefslogtreecommitdiffstats
path: root/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
diff options
context:
space:
mode:
authorMatthewLi <matthew.lijun@huawei.com>2017-06-25 22:04:42 -0400
committerMatthewLi <matthew.lijun@huawei.com>2017-06-25 22:11:20 -0400
commit4e651f34b418668b559093d9020d0d7326a711c5 (patch)
treec159b59beac0563253de9b75a16ba622f2a1671a /docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
parent2a4e39ee4abdbbadf1285a75fb5540a09432b5f4 (diff)
delete old ipv6 files
JIRA: DOVETAIL-452 since https://gerrit.opnfv.org/gerrit/#/c/34577/ merged new ipv6 C&C documents are there, delete the old ones. Change-Id: Ic16cf03b3febd7cca158555e11ecd817ffc61139 Signed-off-by: MatthewLi <matthew.lijun@huawei.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, 0 insertions, 133 deletions
diff --git a/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst b/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
deleted file mode 100644
index 9e403472..00000000
--- a/docs/testing/user/testspecification/old_files/ipv6/designspecification.rst
+++ /dev/null
@@ -1,133 +0,0 @@
-.. 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.