openstack/neutron-specs
Code Issues Proposed changes

VLAN trunking networks for NFV

Browse Source 
How we can create a standardised interface for offering VLAN trunking networks
where use cases require them.

bp nfv-vlan-trunks

Change-Id: I55e882d8f3053f4100558f3f49c2fa0646e3c866
This commit is contained in:
Ian Wells 2014-11-21 21:48:48 -08:00
parent 311d641522
commit 50c3b713ed
1 changed files with 325 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

325
specs/kilo/nfv-vlan-trunks.rst Normal file
View File

@ -0,0 +1,325 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==============================
VLAN trunking networks for NFV
==============================
https://blueprints.launchpad.net/neutron/+spec/nfv-vlan-trunks
Problem Description
===================
Many commonly used Neutron plugin configurations create networks that do
not permit VLAN tagged traffic to transit the network. This includes ML2
when using the OVS driver or the VLAN driver. Some plugins, conversely,
are totally fine at passing all forms of ethernet frame. It's impossible
to tell (via the API) which is in use as a tenant and it's also impossible
to indicate to a plugin what kind of network is required.
VLANs are required for many NFV functions. This spec proposes making it
possible to request a VLAN transparent network - that is, one where VLAN
tagged traffic will be forwarded to other hosts - when one is requested,
and know that a network is in fact a trunk network.
It is a common requirement of NFV VMs that they talk over many
separate L2 channels. The number of channels is far in excess of the
number of ports that the VM has and can change over time. VLAN tags
are often used for separating these channels, so that the number of
ports can be static while still allowing flexibility in the number of
channels.
In Neutron, different network plugins create networks with different
properties, and there is no specific definition of the meaning of the
word 'network'. Mostly, but not always, networks are L2 broadcast
domains with learning-switch behaviour, although as long as antispoof
filters are in place the network can be implemented either as an L2 or
an L3 domain. Generally, as long as networks meet a minimum
requirement that IPv4 and IPv6 unicast traffic, ARPs and NDs, work as
expected, no-one will criticise a plugin. VLAN transparency is not
a part of this current minimum requirement, and some plugins do not,
by oversight or design, allow VLAN packets to flow. It is not possible
to control this behaviour or detect it via the API, and this proposal aims
to change that.
(Other blueprints propose solutions to decomposing trunks into
networks from its individual VLANs, address management on trunk
networks, and so on. This makes no attempt to address anything other
than the simple L2 properties of networks. This spec addresses different
use cases to those that deal with management of ports by Openstack -
specifically, the case where two VLAN-aware VMs wish to talk to each
other over a number of VLANs, possibly with tags that change over time,
and without informing Openstack at each stage of which VLANs and
addresses are in use.)
Proposed Change
===============
This proposal suggests that a request-discover mechanism be put into
place, so that:
* existing plugins that will pass VLAN tagged traffic can identify
themselves as such
* existing plugins that cannot pass VLAN tagged traffic can also
identify themselves as such
* legacy plugins that have not been adapted to report their behaviour
are identifiable
* future plugins can have selective behaviour, where a network may or
may not pass VLAN traffic depending on user request - which permits
the plugin to make decisions in favour of efficiency where the
functionality is not required (such as using an L3 domain).
Additionally, port firewall behaviour - currently undefined for VLAN
tagged packets - will be defined as applying consistently to the outermost
encap of the packet. That is, antispoof and security groups detailing
matching IP ports will apply to packets with an IP ethertype, but will
*not* apply to packets with a VLAN ethertype containing an IP ethertype.
This is because it is highly unlikely that a VLAN will have the same
address and be serving the same services as the VM's untagged interface
on the same vNIC, and so using the same filtering is almost certain to
render the VLAN tagging useless for practical purposes.
Request
-------
During net-create, the user may at their option request that a VLAN
transparent trunk network is created by passing a 'vlan-transparent'
boolean property on the net-create request, request, set to 'true'.
(Setting the property to 'false' is equivalent to not specifying the
property in the description below.)
Plugins that have not been adapted to understand the property will ignore
this flag and create the network regardless.
Plugins that are aware of the meaning of this property but do not
understand the flag, or cannot deliver VLAN transparent trunk networks,
will refuse to create a network and return an appropriate error to
the user.
Plugins that are aware of this flag and capable of delivering a VLAN
transparent network will do so.
Plugins may change behaviour based on this flag:
- they may create a VLAN transparent network (at potentially higher
resource cost) if the flag is set, and save on resources
when it is not set
- they may refuse to attach certain port types to the network
(e.g. some external attachment ports may not themselves be VLAN
transparent and therefore should not be attached to transparent
networks)
Plugins may also only implement one sort of network, either transparent
or not, and decline to create a network when a network is requested
that cannot be implemented by the controller.
In the case that the flag is absent an aware plugin is under no
obligation to deliver a VLAN transparent network (and an unaware
plugin will, naturally, ignore its absence); the returned network may
or may not be VLAN transparent.
Note that the flag cannot be changed by a net-update. VLAN transparency
must be declared at creation and cannot be changed after this point,
as this would potentially affect the placing of the network and even the
choice of endpoints that VMs plug to.
Response
--------
After network creation, a network may have a property
'vlan-transparent'.
In the case that this property does not exist, the plugin
is a legacy plugin and no determination is possible about whether the
network is capable of passing VLAN tagged packets.
In the case that the property exists and the flag is set to true, then
the plugin is a VLAN aware plugin and (regardless of the request)
has created a network capable of passing VLAN tagged packets.
In the case that the property exists and the flag is set to false,
then the plugin is a VLAN aware plugin, the request did not pass the
'vlan-transparent' flag, and for its own reasons the plugin
elected to create a network without VLAN transparency (typically
because it's being efficient or it's simply not capable of doing so).
Per the description in 'request' above, it is possible that the correct
response is an error indicating inability to act upon the request.
Firewalling
-----------
VLAN tagging will be treated as an opaque encapsulation.
VLAN tagged packets will *not* be firewalled by security groups or other
port based security such as antispoofing, as the packet is not an IP
packet. (For those drivers capable of passing VLAN tagged packets, this
is - at least sometimes - a change of behaviour.) This is a deliberate
choice: security groups generally filter packets they understand and pass
packets they don't, so it's consistent (IP-in-MPLS would behave like this)
and it's very likely IP-in-VLAN packets will have different addresses to
any untagged addresses on the same interface, and to each other, and so
Openstack port security will not serve any useful purpose.
This requires validation within the IPTables firewall driver to ensure that
this is the behaviour seen at the moment.
Alternatives
------------
There exists a complementary port-based VLAN spec that permits supplying a
set of networks to a nominated port as a VLAN trunk. It addresses other
use cases and is not a direct alternative.
Data Model Impact
-----------------
'vlan-transparent' property added to networks, a tri-state boolean.
REST API Impact
---------------
On networks:
+-----------------+--------+--------------------+---------+------------+
|Attribute |Type |Access |Default |Validation/ |
|Name | | |Value |Conversion |
+=================+========+====================+=========+============+
|vlan-transparent |tristate|write on create, all|absent |boolean |
| | |readonly after, all | |or absent |
+-----------------+--------+--------------------+---------+------------+
Security Impact
---------------
In current implementations that do pass VLANs, tagged packets'
contents are firewalled. This is not explicitly documented, but is
one behaviour a user might reasonably expect.
This change proposes treating a VLAN tag as an opaque encapsulation,
and thus VLAN tagged packets would *not* be firewalled by their
content. Also, security groups only offer IP-based firewalling, so
it would not be possible to block VLAN tagged packets. That said,
guest OSes can be expected to ignore tagged packets when not
configured for receipt of VLANs, so there should be no impact.
This is in keeping with the behaviour for other non-IP packet types.
Notifications Impact
--------------------
None
IPv6 Impact
-----------
None
Other End User Impact
---------------------
The python-neutronclient should be adjusted to take account of the new
option for net-create and the new property in net-show.
Performance Impact
------------------
May make some plugins more efficient at using network resources.
Other Deployer Impact
---------------------
None.
Developer Impact
----------------
None.
Community Impact
----------------
None.
Implementation
==============
Assignee(s)
-----------
ijw-ubuntu
Work Items
----------
* Implement new net-create parameter
* Implement new network property, including database migration script
* Change a sampling of plugins, including the ML2 plugin, to implement
use of the properties
* Implement a new attr on ML2 drivers indicating whether a driver, when in
use and potentially responsible for a segment of a network, is capable of
passing VLAN packets on that network. The driver may implement settings of
true or false, or the property may be absent in legacy drivers. In the case
that any driver does not have the attribute or has the attribute set to
false, ML2 will decline to create VLAN transparent networks.
* Of the core drivers, the VLAN and OVS drivers will be marked as not
supporting VLAN transparent networks and the LB, VXLAN and GRE drivers
will be marked as supporting VLAN transparent networks. Other drivers
will have legacy behaviour.
* Other plugins will have legacy behaviour until updated and no change is
required of them.
This is *not* changing any driver implementation, merely reporting the
known behaviour of existing drivers. Thus agents are unaffected.
Dependencies
============
None
Testing
=======
Tempest Tests
-------------
Tempest should confirm that (for a known good networking setup) VLAN
transparent networks can be requested from ML2 and that they work.
Such testing should ideally be host to host, to test both the soft switch
and the hardware configuration.
API Tests
---------
API tests should confirm that the property behaves as described
on net-create, net-update and net-show.
Functional Tests
----------------
Functional tests should confirm that ML2 approves and denies creations correctly.
Documentation Impact
====================
User Documentation
------------------
Requires documentation of the new flag.
Developer Documentation
-----------------------
Requires documentation of plugin and MechanismDriver behaviour and
the requirements for supporting VLAN transparent networks for plugins.
References
==========
- https://etherpad.openstack.org/p/juno-nfv-bof
- https://review.openstack.org/#/c/92541/ (composite port support, which
is independent of the status of an individual network)