Bug 1411706 - [RFE] Support Service Function Chaining API with Neutron ML2-OVS reference driver in RHOSP
Summary: [RFE] Support Service Function Chaining API with Neutron ML2-OVS reference dr...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 12.0 (Pike)
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: ---
Assignee: Assaf Muller
QA Contact: Toni Freger
URL: https://launchpad.net/networking-sfc
Whiteboard:
: 1397896 (view as bug list)
Depends On:
Blocks: 1476900 1329354 1501923
TreeView+ depends on / blocked
 
Reported: 2017-01-10 11:06 UTC by Bertrand
Modified: 2020-10-26 12:00 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-03-17 23:48:45 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description Bertrand 2017-01-10 11:06:39 UTC
Scope / Description:
Provide Service Function Chaining API in Neutron rather than a particular driver implementation (ex. NSH with ODL). 
Directly Exposed SFC API by Neutron that can be consumed by many drivers (ODL, Contrail, Nuage..). The goal is to separate the API from the backend implementation; The API does not need to be tight to the implementation; Upstream work taking place can be found at[1]  

[1] https://launchpad.net/networking-sfc


Additional Info:
Partner: Orange
Name: Thomas Morin
Contact Email: Thomas.Morin@orange.com

Red Hat EPM: Bertrand Rault
Contact Email: Brault@redhat.com

Comment 1 Assaf Muller 2017-01-30 23:00:28 UTC
*** Bug 1397896 has been marked as a duplicate of this bug. ***

Comment 2 Bertrand 2017-07-06 08:22:08 UTC
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

Comment 3 Igor Duarte Cardoso 2017-07-06 16:16:30 UTC
(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?

Comment 4 Bertrand 2017-08-16 16:47:16 UTC
(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

Comment 5 Thomas Morin (tmorin) 2017-08-22 08:06:49 UTC
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.

Comment 6 Bertrand 2017-09-30 18:14:01 UTC
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/

Comment 7 Nir Yechiel 2017-10-18 06:38:32 UTC
We have reviewed this feature request and we won't be able to prioritize it for RHOSP 13 due to other priorities.

Comment 8 Nir Yechiel 2018-03-17 23:48:45 UTC
We have no plans to support SFC with ml2/ovs nor OVN in the foreseen future.


Note You need to log in before you can comment on or make changes to this bug.