x/group-based-policy-specs
Code Issues Proposed changes

Merge "introducint TScP and PROXY_GROUP extension"

Browse Source
This commit is contained in:
Jenkins 2015-10-20 18:10:44 +00:00 committed by Gerrit Code Review
commit 0460baf43c
1 changed files with 268 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

268
specs/kilo/gbp-traffic-stitching-plumber.rst Normal file
View File

@ -0,0 +1,268 @@
..
This work is licensed under a Creative Commons Attribution 3.0 Unported
License.
http://creativecommons.org/licenses/by/3.0/legalcode
==========================================
Traffic Stitching Plumber
==========================================
Problem description
===================
As part of the service chain refactor effort [0] GBP now supports the ability to provision
"node centric" service chains that are composed of interoperable multi-vendor service
nodes linked by a Plumber, which takes care of placing the services in the underlying
infrastructure in a way that complies with the user intent.
Each Node Driver will expose a set of networking requirements via the get_plumbing_info
API, that will be used by the plumber to ensure that the traffic flows correctly.
As for today, the only plumber implementation we have (obviously intended as a placeholder
for testing) just blindly add Policy Targets to the provider and the consumer
groups, making the chain ordering useless and traffic flowing incorrect.
This document will address the design of a Plumber that will guarantee traffic
to flow as expected throughout the chain, in the order specified by the SCS.
Proposed change
===============
The proposal of this blueprint is to implement a Traffic Stitching Plumber (TScP)
that uses the GBP underlying constructs in order to guarantee a correct traffic flow
across services from their provider to the consumer and vice versa.
As discussed in [0] the output of the plumbing operations will be either the creation or
deletion of a set of Service Targets, which effectively result in creation of Policy Targets exposed
to the specific Node Driver for its own use. In addition to that, TScP will create a set of L2Ps
and/or PTGs that are "stitched" together and host the actual service PTs.
The creation of said plumber, will be divided in three macro steps:
1. Introduction of the PROXY_GROUP driver extension, an extension of the base
GBP API that introduces a way to "proxy" a PTG with another that "eats" all
the incoming and outgoing traffic from the original PTG;
2. Make RMD compliant with the PROXY_GROUP extension;
3. Implement the TScP, that will exclusively make use of existing GBP constructs
(and proxy_group extension) in order to deploy the chain. This will guarantee
interoperability across multiple backend solutions.
PROXY_GROUP driver extension.
The main functionality exposed by this extension is the ability to put a PTG
"in front" of an existing one (in a linked list fashion). Whenever a PTG
proxies another, all the traffic going to the original PTG will have to go
through the proxy fist. Traffic from the Proxy through the original group will
go through a special PT that has the proxy_gateway flag set to True.
In addition to the above, a new "group_default_gateway" attribute is introduced
for PTs, that indicates a special PT that will take the default gateway address
for a given group (typically enforced by reserving the corresponding Neutron
Subnet address). The flow representation below describes how traffic flows
from a L3P (for simplicity) to a PTG proxied by another:
asciiflow::
+---+ +-------+
| | | | +-------+
| | +--------------+ +-----------+ | |
|PTG<-----> proxy_gateway| PROXY | group dgw <-----> L3P |
| | +--------------+ +-----------+ | |
| | | | +-------+
+---+ +-------+
There are two types of Proxies: L2 and L3 proxy. A L2 proxy will share the
same subnets as the original group (at least at the CIDR level, may be different
Neutron's subnets). In a L2 Proxy traffic is supposed to go through the proxy
without being routed. A L3 proxy will route traffic to the original group,
and will have its own subnet coming from a proxy_ip_pool, new attribute that
extends the L3P.
Note that this extension will be exclusively for *internal* use! Meaning that
the TScP is likely the only entity that will even make use of this API.
RMD compliance with PROXY_GROUP extension.
The RMD will use existing Neutron constructs for implementing the PROXY_GROUP
extension using the semantic described above. More specifically, whenever a
Proxy is put in front of a PTG, the latter will be detached from the L3P router and
replaced by the Proxy. Is then expected that a proxy_gateway PT is created and
a proper function (depending from the proxy type) is created for ensuring traffic
flow.
In case of L3 proxies, the subnet allocation will happen just like it does for
normal PTGs, but from a different Pool (proxy_ip_pool). Also, routes need
to be updated properly across the Neutron subnets/routers when a L3 Proxy
is used.
TScP implementation.
The last step of the implementation is the TScP itself. By using the new
PROXY_GROUP constructs, the TScP plumber will take care of setting up the
Service Chain datapath.
Depending on the plumbing type used (defined in a different blueprint) the
TScP will create the correct proxy type and PTs to be provided to the node
driver for the actual service plugging to happen. Support for a management
PTG will also be implemented.
Data model impact
-----------------
A number of tables are created for the PROXY_GROUP extension to work:
GroupProxyMapping (gp_group_proxy_mappings):
* policy_target_group_id - proxy PTG UUID;
* proxied_group_id - UUID of the proxied PTG
* proxy_group_id - UUID of the current PTG's proxy
* proxy_type - ENUM (L2/L3)
ProxyGatewayMapping(gp_proxy_gateway_mappings):
* policy_target_id - PT UUID
* proxy_gateway - Bool indicating whether this PT is a gateway to proxy
* group_default_gateway - Bool indicating whether this PT is the DG for its PTG
ProxyIPPoolMapping(gp_proxy_ip_pool_mapping):
* l3_policy_id - L3P UUID
* proxy_ip_pool - IP pool (address/cidr) to be used for L3 proxies
* proxy_subnet_prefix_length - Iterger value, prefix len for the proxy subnets
REST API impact
---------------
The REST API changes look like follows (note that they only ally if the PROXY_GROUP
extension is configured)::
EXTENDED_ATTRIBUTES_2_0 = {
gp.POLICY_TARGET_GROUPS: {
'proxied_group_id': {
'allow_post': True, 'allow_put': False,
'validate': {'type:uuid_or_none': None}, 'is_visible': True,
'default': attr.ATTR_NOT_SPECIFIED,
'enforce_policy': True},
'proxy_type': {
'allow_post': True, 'allow_put': False,
'validate': {'type:values': ['l2', 'l3', None]},
'is_visible': True, 'default': attr.ATTR_NOT_SPECIFIED,
'enforce_policy': True},
'proxy_group_id': {
'allow_post': False, 'allow_put': False,
'validate': {'type:uuid_or_none': None}, 'is_visible': True,
'enforce_policy': True},
# TODO(ivar): The APIs should allow the creation of a group with a
# custom subnet prefix length. It may be useful for both the proxy
# groups and traditional ones.
},
gp.L3_POLICIES: {
'proxy_ip_pool': {'allow_post': True, 'allow_put': False,
'validate': {'type:subnet': None},
'default': '192.168.0.0/16', 'is_visible': True},
'proxy_subnet_prefix_length': {'allow_post': True, 'allow_put': True,
'convert_to': attr.convert_to_int,
# for ipv4 legal values are 2 to 30
# for ipv6 legal values are 2 to 127
'default': 29, 'is_visible': True},
# Proxy IP version is the same as the standard L3 pool ip version
},
gp.POLICY_TARGETS: {
# This policy target will be used to reach the -proxied- PTG
'proxy_gateway': {
'allow_post': True, 'allow_put': False, 'default': False,
'convert_to': attr.convert_to_boolean,
'is_visible': True, 'required_by_policy': True,
'enforce_policy': True},
# This policy target is the default gateway for the -current- PTG
# Only for internal use.
'group_default_gateway': {
'allow_post': True, 'allow_put': False, 'default': False,
'convert_to': attr.convert_to_boolean,
'is_visible': True, 'required_by_policy': True,
'enforce_policy': True},
},
}
Security impact
---------------
Notifications impact
--------------------
Other end user impact
---------------------
Performance impact
------------------
Other deployer impact
---------------------
TBD
Developer impact
----------------
TBD
Community impact
----------------
Alternatives
------------
Implementation
==============
Assignee(s)
-----------
* Ivar Lazzaro (mmaleckk)
Work items
----------
Dependencies
============
Testing
=======
Tempest tests
-------------
Functional tests
----------------
API tests
---------
Documentation impact
====================
User documentation
------------------
Developer documentation
-----------------------
References
==========
[0] https://github.com/stackforge/group-based-policy-specs/blob/master/specs/kilo/gbp-service-chain-
driver-refactor.rst