Neutron extension to support service chaining

[cathy Hong Zhang]

In current Data Center, the deployment of service chain for a tenant's flow is through static, complex, and rigid configurations since they are tightly coupled with physical network topology and physical resources. The introduction of new services into a network usually requires the reconfiguration of most (if not all)
network elements. This is not acceptable in cloud environment. To reduce the OPEX and increase agility, automatic setup of service chain according to user's service chain requirement specification is needed. There is already a BP submitted on service chain use case https://review.openstack.org/#/c/169201/4

Currently Neutron does not support service chaining. To support service chaining, Service VMs must be attached to points of the network and then traffic must be steered between these attachment points.

There are two steps in creating a service chain. First, Services VMs (such as FW VM) need to be created and connected to a Neutron network via Neutron ports. After that, selected traffic flows need to be steered through an ordered sequence of these service VM ports. Current OpenStack already support creation of service VMs and attachment of these service VMs to Neutron network ports. What is missing is an API to specify classification rules of the selected flow and the sequence of service VM ports the selected flow needs to go through so that it can get the desired service treatment. Neutron API can be extended to fill in this gap. This new "port chain" API does not need to know the actual services attached to these Neutron ports since the Service VM creation API already has this information.

In summary, first the service function is instantiated and connected to the network through Neutron ports. Once the service function is attached to Neutron ports, the ports are included in a "port chain" to allow the service function to provide treatment to the user's traffic.

[yalei wang (yalei-wang)]

is this bug for this bp? https://review.openstack.org/#/c/176999/1/specs/liberty/neutron-api-for-service-chaining.rst

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

Yes

[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

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

Hi Armando,

Thank you very much for triaging this bug and your suggestion of starting a new project for faster iteration.

Since your reply says this project/feature should be part of the Neutron Tent, I have gone through the email thread discussing the Neutron Tent. Following are some questions which I would appreciate your clarification:

1. When setting up a new repo for this project, should we create the repo under OpenStack/Neutron/ namespace ? If not, which namespace should it be?

2. Shall we add an entry for this project under Neutron in reference/projects.yaml as stated in the neutron Tent email thread?

3. You mentioned that we'd want SFC to plug back into the Neutron core where it makes sense and the missing pieces that would be required for tighter integration with the core. I plan to discuss with the team and identify the specific pieces of work that need to be plug back into Neutron in next week's IRC meeting. Once we agree on the piece, I will submit a new bug or update this bug.

4. By "a new team", you mean registering a team for service chain project in launchpad.net, right?

Also thanks for your offer of helping creating the repo, IRC meeting etc. I know you are very busy as a core member and I can take care of creating the repo, meeting, and team once I get clarification on my above questions. I have a list of people from various companies who have expressed interest in contributing to this project. As to the weekly IRC meeting, per request of people, several weeks ago I already set that up and sent the info to the openstack-dev. I will start the IRC meeting next Thursday and send out a reminder next week.

Cathy

[Armando Migliaccio (armando-migliaccio)]

Hi Cathy, please see my responses below:

1) The way this has worked we have worked so far is by:

a) creating the project in stackforge
b) start the development effort
c) at a later date, once some meaningful progress has been achieved you 'apply' your project for inclusion
d) you can transition under the openstack namespace in due course.

For instance this process was adopted by OVN, this resulted into these major changes:

https://review.openstack.org/#/c/158137/
https://review.openstack.org/#/c/184159/
https://review.openstack.org/#/c/184159/

The L2GW and other projects went through the same process.

2) This can way until you first accomplish a) and b) (build the team and start development and get to some deployable software :))

3) We can either use a new bug and mark this invalid, or reuse this bug. Either way is fine.

4) That is part of the project of creating a new project. More instructions available at:

http://docs.openstack.org/infra/manual/creators.html

HTH
Armando

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

Hi Armando,

Thanks for your reply. I am a little confused. After introduction of the Big Tent, isn't Stackforge going away?

Thanks,
Cathy

[Armando Migliaccio (armando-migliaccio)]

Yes, eventually, but I am not sure about timelines.

If you look at the current project-config backlog [1], there are plenty of active requests for the creation of stackforge projects. For further details, I'd suggest you to reach out folks on #openstack-infra on Freenode.

Cheers,
Armando

[1] https://review.openstack.org/#/q/status:open+project:openstack-infra/project-config,n,z

[Akihiro Motoki (amotoki)]

The actual activity is in progress in networking-sfc project.
I wonder what is the best way to handle this RFE bug.

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

Akihiro,

Yes, the activity is in progress in networking-sfc. We can use this bug as a place holder to include this feature in OpenStack release when the codes are ready and merged. What do you think?

Thanks,
Cathy

-----Original Message-----
From: <email address hidden> [mailto:<email address hidden>] On Behalf Of Akihiro Motoki
Sent: Tuesday, October 06, 2015 3:39 AM
To: Cathy Zhang
Subject: [Bug 1450617] Re: Neutron extension to support service chaining

The actual activity is in progress in networking-sfc project.
I wonder what is the best way to handle this RFE bug.

--
You received this bug notification because you are subscribed to the bug report.
https://bugs.launchpad.net/bugs/1450617

Title:
  Neutron extension to support service chaining

Status in neutron:
  Triaged

Bug description:
  In current Data Center, the deployment of service chain for a tenant's flow is through static, complex, and rigid configurations since they are tightly coupled with physical network topology and physical resources. The introduction of new services into a network usually requires the reconfiguration of most (if not all)
  network elements. This is not acceptable in cloud environment. To reduce the OPEX and increase agility, automatic setup of service chain according to user's service chain requirement specification is needed. There is already a BP submitted on service chain use case https://review.openstack.org/#/c/169201/4

  Currently Neutron does not support service chaining. To support
  service chaining, Service VMs must be attached to points of the
  network and then traffic must be steered between these attachment
  points.

  There are two steps in creating a service chain. First, Services VMs
  (such as FW VM) need to be created and connected to a Neutron network
  via Neutron ports. After that, selected traffic flows need to be
  steered through an ordered sequence of these service VM ports. Current
  OpenStack already support creation of service VMs and attachment of
  these service VMs to Neutron network ports. What is missing is an API
  to specify classification rules of the selected flow and the sequence
  of service VM ports the selected flow needs to go through so that it
  can get the desired service treatment. Neutron API can be extended to
  fill in this gap. This new "port chain" API does not need to know the
  actual services attached to these Neutron ports since the Service VM
  creation API already has this information.

  In summary, first the service function is instantiated and connected
  to the network through Neutron ports. Once the service function is
  attached to Neutron ports, the ports are included in a "port chain" to
  allow the service function to provide treatment to the user's traffic.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1450617/+subscriptions