[openstack-dev] [neutron][policy] Integrating network policies and network services

Mohammad Banikazemi mb at us.ibm.com
Mon Mar 17 19:04:38 UTC 2014


Kanzhe, thanks for your response to my comments and questions. Please see
below.

> From: Kanzhe Jiang <kanzhe at gmail.com>
>
[...]
>> On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi <mb at us.ibm.com>
wrote:
>>
[...]
>> 3- For the service chain creation, I am sure there are good reasons
>> for requiring a specific provider for a given chain of services but
>> wouldn't it be possible to have a generic "chain" provider which
>> would instantiate each service in the chain using the required
>> provider for each service (e.g., firewall or loadbalancer service)
>> and with setting the insertion contexts for each service such that
>> the chain gets constructed as well? I am sure I am ignoring some
>> practical requirements but is it worth rethinking the current approach?

> Service Chaining often means a form of traffic steering. Depending
> on how the steering is done, the capabilities of different providers
> differ. Different provider may define different context of
> individual service in the chain. For example, a bump-in-the-wire
> service can be inserted as a virtual wire or L3 next hop. So it will
> be hard to define a "generic" chain provider.

With respect to Question 3 above, yes you are right we need possibly
different providers for this generic "chain" service type. The solution
could be having the "chain" as a service type itself which can be provided
by different providers. Different providers can implement the instantiation
of a chain differently. This is similar to the current service-chain model
in that there may be different providers for a service-chain with the
difference being that the service type itself is generic and not specific
to a particular chain such as firewall-vpn.

Best,

Mohammad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/6b77a682/attachment.html>


More information about the OpenStack-dev mailing list