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

Status:
Complete
Approver:
Louis Fourie
Priority:
Undefined
Drafter:
Louis Fourie
Direction:
Needs approval
Assignee:
Louis Fourie
Definition:
Approved
Series goal:
Accepted for pike
Implementation:
Implemented
Milestone target:
milestone icon queens-1
Started by
Louis Fourie on 2017-05-21
Completed by
Louis Fourie on 2017-11-30

Related branches

Sprints

Whiteboard

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.