View source for Blueprint-networking-vpp-taas

== 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 ==
TaaS has no blueprint, but here are usefull links:
* [https://github.com/openstack/tap-as-a-service github source code]
* [https://launchpad.net/tap-as-a-service TaaS Launchpad ]

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,

[[File:TaaS VPP.png|thumb|center]]

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/'.

In order to support a meshed TaaS (ie multiple flows to multiple services), the possible implementation is the following:
- the vhost-user interface is spanned to a loopback interface, this loop0belongs to the 'flow' bridge domain
- we copy the packets from the flow bridge domain to the 'service' bridge domain, which includes:
* the appropriate vlan sub interface
* possibly the destination vhost-user.

[[File:TaaS VPP - 2.png|thumb|center]]