SFC Port-pair Tap

Registered by Louis Fourie on 2017-03-02

There are some SFs that operate in a passive mode and only receive packets on the ingress port but do not send packets on an egress port. An example of this is an Intrusion Detection Service (IDS). In order to include such a SF in a port chain, the packets must be delivered to this SF and also forwarded on to the next downstream SF in the port chain.

This type of SF will be marked as "tap" and the data-plane switch behavior will be to send the packets to the ingress port of the SF and also forward these packets to the ingress port of the next hop SF. This port-pair will in effect operate as a tap by passing packets to the passive SF and also forwarding these packets to the next downstream SF.

Blueprint information

Louis Fourie
Louis Fourie
Needs approval
Louis Fourie
Series goal:
Accepted for pike
Milestone target:
milestone icon queens-1
Started by
Louis Fourie on 2017-05-21
Completed by
Louis Fourie on 2017-11-30

Related branches



Question: is there a use case for "tap chains"? I.e. not only you send traffic to your tap function, but then your tap function also sends traffic to a next hop too, so a full chain starts after traffic gets tapped at the first chain (the first chain also continues).

There is a specific use case where the tap SF if a passive device such as an IDS

Gerrit topic: https://review.openstack.org/#q,topic:bp/sfc-tap-port-pair,n,z

Addressed by: https://review.openstack.org/449954
    [WIP] API changes for Passive TAP SF

Addressed by: https://review.openstack.org/465057
    [WIP] Driver changes for TAP SF support in portchain


Work Items

This blueprint contains Public information 
Everyone can see this information.