Merge "introducint TScP and PROXY_GROUP extension"
This commit is contained in:
Jenkins
Gerrit Code Review
commit
0460baf43c
268
specs/kilo/gbp-traffic-stitching-plumber.rst
Normal file
268
specs/kilo/gbp-traffic-stitching-plumber.rst
Normal 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
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user