GBP Floating IP Support for Policy Target(s)
Introduce the model for Floating IP support for PTs Change-Id: I5f15963d41958ce28fb5294f458ea15011b11aef Implements: blueprint gbp-floating-ip-support
This commit is contained in:
parent
e24fb015a6
commit
3d8d40b63b
|
@ -0,0 +1,132 @@
|
||||||
|
..
|
||||||
|
This work is licensed under a Creative Commons Attribution 3.0 Unported
|
||||||
|
License.
|
||||||
|
http://creativecommons.org/licenses/by/3.0/legalcode
|
||||||
|
|
||||||
|
==========================================
|
||||||
|
GBP Floating IP Policy
|
||||||
|
==========================================
|
||||||
|
|
||||||
|
Launchpad blueprint:
|
||||||
|
|
||||||
|
https://blueprints.launchpad.net/group-based-policy/+spec/gbp-floating-ip-support
|
||||||
|
|
||||||
|
|
||||||
|
Problem description
|
||||||
|
===================
|
||||||
|
|
||||||
|
The existing GBP APIs do not provide a way of defining a policy to create or associate floating IPs with a Policy Target.
|
||||||
|
|
||||||
|
Proposed change
|
||||||
|
===============
|
||||||
|
|
||||||
|
The Network Service Policy resource in GBP, at present supports allocating a single IP address from a given PTG subnet. This is achieved by creating a Network Service Parameters dictionary with type ip_single and value self_subnet to indicate that a single IP Address has to be allocated from the PTG subnet to which the Network Service Policy is attached.
|
||||||
|
This is used in Network Services, where when we have a redirect to a Loadbalancer, the IP for the VIP comes from GBP.
|
||||||
|
This network_service_params in Network Service Policy will be extended to add a new type ip_pool and a new value nat_pool to represent the Floating IP Allocation Policy.
|
||||||
|
When we have a something like a Advanced Services management PTG, where we require all PTs on that PTG to get a floating IP associated to the port. This will be achieved by attaching a Network Service Policy of type ip_pool and value nat_pool to the PTG.
|
||||||
|
Another use case to be supported is a PTG whose PTs provide a particular service and there is a Loadbalancer in front. In this case, the Loadbalancer VIP requires a floating IP to be associated if it is for North-South traffic. This will be achieved by attaching a Network Service Policy of type ip_single and value nat_pool to the Provider PTG. The allocated floating IP in this case will be sent in config_param_values to Service Chain.
|
||||||
|
|
||||||
|
Reference Implementation:
|
||||||
|
When a PT is created, the Resource Mapping Driver shall retrieve the Network Service Policy defined for the PTG. If there is a Network Service Parameter with type ip_pool and value nat_pool, the external segment is retrieved from the L3 Policy the PTG belongs to. From the external segment the nat pool is fetched and then a Floating IP is allocated out of the nat pool and associated with the PT port.
|
||||||
|
For backward compatibility with Juno, the nat_pool resource will be forced to have the same ip_pool CIDR as the external subnet.
|
||||||
|
|
||||||
|
Network Service Policy create or update operations shall raise an error if an external segment having a nat pool is not associated with the L3Policy for the PTGs the NSP refers to.
|
||||||
|
|
||||||
|
Alternatives
|
||||||
|
------------
|
||||||
|
|
||||||
|
All PTGs on a L3Policy that has a external segment configured with a nat pool shall get floating IP associated with all the PTs without the need for a Network Service Policy. The main disadvantage with this approach is that there is no fine grained control with the Floating IP association with implicit external segment association with a L3Policy, in which case all the PTs will end up getting a Floating IP.
|
||||||
|
|
||||||
|
Data model impact
|
||||||
|
-----------------
|
||||||
|
|
||||||
|
None.
|
||||||
|
|
||||||
|
REST API impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Security impact
|
||||||
|
---------------
|
||||||
|
|
||||||
|
Policy Targets within the cloud reach the external world and outside world can reach
|
||||||
|
the Policy Targets when they get a FIP.
|
||||||
|
The security implications depend on the way the PRS are composed by the cloud admin.
|
||||||
|
or the Policy Target Group's policy targets to be accessible at their floating IPs from the external world, the PTG needs to have the following properties:
|
||||||
|
- The L3P it belongs to must have at least one external segment and one nat pool associated with the external segment.
|
||||||
|
- The External Segment must have at least one route.
|
||||||
|
- An External Policy should be associated with the External Segment.
|
||||||
|
- The PTG should provide/consume a PRS that allows traffic with a specific classifier.
|
||||||
|
- The External Policy should consume/provide that particular PRS.
|
||||||
|
- Traffic destined to the Floating IP, and satisfying the PRS criteria, will be NAT'ed and will reach the corresponding internal IP in the PTG.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
This blueprint has no impact on notifications.
|
||||||
|
|
||||||
|
Notifications impact
|
||||||
|
--------------------
|
||||||
|
|
||||||
|
This blueprint has no impact on notifications.
|
||||||
|
|
||||||
|
Other end user impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
The python client and the UI have to expose the new model
|
||||||
|
to the end user.
|
||||||
|
|
||||||
|
Performance impact
|
||||||
|
------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Other deployer impact
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Developer impact
|
||||||
|
----------------
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Implementation
|
||||||
|
==============
|
||||||
|
|
||||||
|
Assignee(s)
|
||||||
|
-----------
|
||||||
|
|
||||||
|
Primary assignee:
|
||||||
|
Magesh GV (magesh-gv)
|
||||||
|
|
||||||
|
Other contributors:
|
||||||
|
None
|
||||||
|
|
||||||
|
Work items
|
||||||
|
----------
|
||||||
|
|
||||||
|
- Database and API;
|
||||||
|
- Neutron mapping driver;
|
||||||
|
|
||||||
|
Dependencies
|
||||||
|
============
|
||||||
|
|
||||||
|
None
|
||||||
|
|
||||||
|
Testing
|
||||||
|
=======
|
||||||
|
|
||||||
|
New unit tests will be added for the floating IP model, and existing
|
||||||
|
unit tests for the mapping will be updated when needed.
|
||||||
|
|
||||||
|
Documentation impact
|
||||||
|
====================
|
||||||
|
|
||||||
|
Eventual GBP documentation will need to address configuration
|
||||||
|
of Network Service Policy to associate floating IP.
|
||||||
|
|
||||||
|
References
|
||||||
|
==========
|
||||||
|
|
||||||
|
None
|
Loading…
Reference in New Issue