Difference between revisions of "Blueprint-networking-vpp-taas"
(Possible implementation to add TaaS feature to networking-vpp) |
m |
||
| Line 1: | Line 1: | ||
| + | == Purpose of this BP == | ||
The goal of this document is to propose to add an implementation of a TaaS driver for networking-vpp. | The goal of this document is to propose to add an implementation of a TaaS driver for networking-vpp. | ||
Actual OVS driver for Tap as a Service uses openflow rules. With the port mirroring plugin in VPP, we should be able to implement the same feature, using the same API. | Actual OVS driver for Tap as a Service uses openflow rules. With the port mirroring plugin in VPP, we should be able to implement the same feature, using the same API. | ||
| − | + | ||
== Relationship with other blueprint == | == Relationship with other blueprint == | ||
As we leverage the existing TaaS model, we rely mainly on it. | As we leverage the existing TaaS model, we rely mainly on it. | ||
| Line 11: | Line 12: | ||
Same as TaaS: debug, probe, IDS, etc. | Same as TaaS: debug, probe, IDS, etc. | ||
| − | == | + | == Possible implementations == |
Two sides of the implementation should be considered: | Two sides of the implementation should be considered: | ||
- the VPP part, on which the python API is built on, needs to have the port mirroring feature enabled. This is not addressed in this document | - the VPP part, on which the python API is built on, needs to have the port mirroring feature enabled. This is not addressed in this document | ||
Revision as of 13:46, 26 October 2016
Contents
Purpose of this BP
The goal of this document is to propose to add an implementation of a TaaS driver for networking-vpp. Actual OVS driver for Tap as a Service uses openflow rules. With the port mirroring plugin in VPP, we should be able to implement the same feature, using the same API.
Relationship with other blueprint
As we leverage the existing TaaS model, we rely mainly on it. The main points are: - tenant isolation - selection of the direction of the captured packets (ingress, egress, booth)
Use cases
Same as TaaS: debug, probe, IDS, etc.
Possible implementations
Two sides of the implementation should be considered: - the VPP part, on which the python API is built on, needs to have the port mirroring feature enabled. This is not addressed in this document - the Neutron plugin part, which is the object of this documentation
Two main possibilities exist to implement this feature:
- Implement a TaaS driver side by side with the existing networking-vpp ml2 plugin
- Implement at the TaaS Plugin level, leveraging the work done on etcd to store all required information, as well as the integration with VPP python api.
In booth cases, we should stick to the existing TaaS api to ensure cross project compatibility,
In this latter case, the TaaS server can update the etcd database used by networking-vpp using a new root path: Existing etcd paths are : /networking-vpp/nodes/<node-name>/ports/ /networking-vpp/state/<node-name>/ports/ /networking-vpp/state/<node-name>/physnets/
We may add taas imformation per node under '/networking-vpp/nodes/<node-name>/taas/'.
Upon notification of a new element under this path, the networking-vpp agent will configure accordingly vpp and report the state under '/networking-vpp/state/node-name>/taas/'.
