common service chaining driver API

[cathy Hong Zhang]

This feature/bug is related to bug #1450617 (Neutron extension to support service chaining)

Bug #1450617 is to add a neutron port chaining API and associated "neutron port chain manager" to support service chaining functionality. Between the "neutron port manager" and the underlying service chain drivers, a common service chain driver API shim layer is needed to allow for different types of service chain drivers (eg. OVS driver, different SDN Controller drivers) to be integrated into the Neutron. Different service chain drivers may have different ways of constructing the service chain path and use different data path encapsulation and transport to steer the flow through the chain path. With one common interface between the Neutron service chain manager and various vendor-specific drivers, the driver design/implementation can be changed without changing the Neutron Service Chain Manager and the interface APIs.

This interface should include the following entities:

 * An ordered list of service function instance clusters. Each service instance cluster represents a group of like service function instances which can be used for load distribution.
 * Traffic flow classification rules: It consists of a set of flow descriptors.

[Eugene Nikanorov (enikanorov)]

Usually new features are tracked via blueprints, not bugs, and require spec to be merged.

Is there a blueprint regarding this feature?

[cathy Hong Zhang (cathy-h-zhang)]

Yes, there is a BP for this. https://blueprints.launchpad.net/neutron/+spec/common-service-chaining-driver-api
https://review.openstack.org/#/c/177946

You can sign up and review the spec for the BP.

This bug is created based on the new Neutron feature request process.

[Armando Migliaccio (armando-migliaccio)]

Guidelines, details on how to write RFE's, and the process for handling features if you have already submitted specs in the past, but are yet to be complete. can be found here:

https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst

For more details, please reach out on #openstack-neutron or openstack-dev ML [neutron].

[Armando Migliaccio (armando-migliaccio)]

Cathy, both bug 1450617 and bug 1450625 make a lot of sense.

Bear in mind that the RFE bugs are not strictly necessary since your spec proposal predates the change in the feature submission process.

I think that the scope of this feature is large enough to have this be developed in autonomy, without too much oversight from the Neutron drivers team, and without too much burden due to process.

What I mean by this is that we should consider starting a new project (but still part of the Neutron tent), where we can iterate and experiment faster than we could in the Neutron core. This means setting up a new repo, a new weekly meeting, new team, etc.

I can help you setting up all of this, if you are a bit lost.

The amount of work that the drivers team is asked to review has become so vast these days, that having smaller and more focused teams collaborate in isolation is the most sensible way to achieve progress in a timely manner.

Having said that, we'd want SFC to plug back into the Neutron core where it makes sense, and for the missing pieces that would be required for tighter integration with the core, we can follow the RFE process defined in [1]. The drivers team should have enough capacity to provide input and guidance on RFE's of a much smaller scope.

If you have any question, please feel free to reach out to us on #openstack-neutron or openstack-dev ML [neutron].

Thanks,
Armando

[1] https://github.com/openstack/neutron/blob/master/doc/source/policies/blueprints.rst

[xiaodongwang (xiaodongwang991481)]

On Tue, Oct 6, 2015 at 9:21 PM, Armando Migliaccio <
<email address hidden>> wrote:

> ** Also affects: networking-sfc
> Importance: Undecided
> Status: New
>
> ** No longer affects: neutron
>
> --
> You received this bug notification because you are a member of
> networking-sfc-bugs, which is subscribed to networking-sfc.
> https://bugs.launchpad.net/bugs/1450625
>
> Title:
> common service chaining driver API
>
> Status in networking-sfc:
> New
>
> Bug description:
> This feature/bug is related to bug #1450617 (Neutron extension to
> support service chaining)
>
> Bug #1450617 is to add a neutron port chaining API and associated
> "neutron port chain manager" to support service chaining functionality.
> Between the "neutron port manager" and the underlying service chain
> drivers, a common service chain driver API shim layer is needed to allow
> for different types of service chain drivers (eg. OVS driver, different
> SDN Controller drivers) to be integrated into the Neutron. Different
> service chain drivers may have different ways of constructing the service
> chain path and use different data path encapsulation and transport to steer
> the flow through the chain path. With one common interface between the
> Neutron service chain manager and various vendor-specific drivers, the
> driver design/implementation can be changed without changing the Neutron
> Service Chain Manager and the interface APIs.
>
> This interface should include the following entities:
>
> * An ordered list of service function instance clusters. Each service
> instance cluster represents a group of like service function instances
> which can be used for load distribution.
> * Traffic flow classification rules: It consists of a set of flow
> descriptors.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/networking-sfc/+bug/1450625/+subscriptions
>