Bug 1411706

*** Bug 1397896 has been marked as a duplicate of this bug. ***

Additional information following discussion with partner:
There is a reference driver proposed in Neutron based on OpenFlow rule. ( e.g for such and such flow, direct it to given compute) Driver neutron manage the flow definition [1]  (Flows can be pro-actively defined vs being simply discovered and populated in flow table at “runtime”). 
Partner developped an alternate driver based on bagpipe. This is an extension of bagpipe that creates an association between the tuples / flow and a given vpn which will then be known by each compute. In other words, bagpipe will be able to tell which flow belongs to which VPN.
Compute will also exchange bgp routes between each other to insure end to end connectivity as part of SFC.
Current status is that API is in working progress and should be able to do SFC based on BGP VPN protocol soon.
 
[1] https://docs.openstack.org/developer/networking-sfc/ovs_driver_and_agent_workflow.html#problem-description

(In reply to Bertrand from comment #2)
> Current status is that API is in working progress and should be able to do
> SFC based on BGP VPN protocol soon.

And this API will be an extension to networking-sfc's?

(In reply to Bertrand from comment #2)
> Additional information following discussion with partner:
> There is a reference driver proposed in Neutron based on OpenFlow rule. (
> e.g for such and such flow, direct it to given compute) Driver neutron
> manage the flow definition [1]  (Flows can be pro-actively defined vs being
> simply discovered and populated in flow table at “runtime”). 
> Partner developped an alternate driver based on bagpipe. This is an
> extension of bagpipe that creates an association between the tuples / flow
> and a given vpn which will then be known by each compute. In other words,
> bagpipe will be able to tell which flow belongs to which VPN.
> Compute will also exchange bgp routes between each other to insure end to
> end connectivity as part of SFC.
> Current status is that API is in working progress and should be able to do
> SFC based on BGP VPN protocol soon.
>  
> [1]
> https://docs.openstack.org/developer/networking-sfc/
> ovs_driver_and_agent_workflow.html#problem-description

Hi Thomas,

As discussed, could you review comment#2 for accuracy as this may have have been mischaracterized and also review comment#3. 

Thank you,

Bertrand

About Bertrand's comment#2 and your question Igor in comment#3:

The service chaining work in progress with networking-bagpipe (not yet upstream, but should be soonish) is *not* a new service chaining API *nor* an extension of networking-sfc API.

The goal is to provide a driver for networking-sfc internally relying on BGP VPN and BGP FlowSpec VPN routes to build the service chains. The idea is to implement that in a way that make it natural to implement service chains that attract traffic from external BGP VPNs (not only from DC virtual networks with VMs). The idea is also to see how it plays out (like with networking-bagpipe for ML2) move the information distribution load from the message bus to BGP route exchanges.

Igor, to your question: we are implementing networking-sfc API with a driver, not extending it nor replacing it.  To plug BGPVPNs and service chain,  nothing's settled at all, but the idea that I find would work well would consist in: extending the BGPVPN API to associate a (Common Flow Classifier ID, SFC port-chain ID) tuple to indicated that the traffic from this BGPVPN matching the classifier should go into the chain.

This comment is to recenter the focus of this RFE around the ask for support of the Service Function Chaining API [1] with ML2-OVS reference driver in RHOSP. 
The support for the networking-bagpipe as a backend driver is not in scope here.

Motivation:
"The SFC API from the networking-sfc project [1]
allows:
(a) the use of service chaining without being tied to an API
specific to a given SDN controller, 
and 
(b) the use of service chaining with the Neutron ML2 OVS reference driver."

[1] https://docs.openstack.org/networking-sfc/latest/

We have reviewed this feature request and we won't be able to prioritize it for RHOSP 13 due to other priorities.

We have no plans to support SFC with ml2/ovs nor OVN in the foreseen future.