Open Stack

Hi, Apologies for chiming in late on this. Yes, we have been
incubating the service insertion and chaining features [2] for some
time now. The plan was to have a FW-VPN chain working by Icehouse
release. Towards that end the first step was to introduce the notion
of a service insertion context which forms the foundation for the
service chain resource. The following patch aims to address the
service insertion context:
https://review.openstack.org/#/c/62599/

and we hope to get the above merged into Icehouse. However, it does
not seem like we will be able to land the service chaining in
Icehouse. That said we are hoping to introduce WIP patches soon that
will implement the ideas so far discussed.

We had regular IRC meetings earlier on the topic of "advanced
services", but we suspended those temporarily so as not to distract
from the Neutron stabilization and parity work underway in Icehouse.
We hope to get back to those meetings once the critical bugs and
features slated for Icehouse are out of the way.

Per your question in the context of the Group Policy work, these two
features are indeed complementary. As pointed out in this thread, one
of the options for rendering the Groups Policies is on top of
elemental Neutron abstractions as service chains expressed in [2].
Also as pointed out in another email thread, we will specifically
touch on this topic in the upcoming Group Policy meetings.

Thanks,
~Sumit.



On Wed, Feb 12, 2014 at 10:21 AM, Stephen Wong <s3wong at midokura.com> wrote:
> Hi Carlos,
>
>
> On Wed, Feb 12, 2014 at 9:37 AM, Carlos Gonçalves <mail at cgoncalves.pt>
> wrote:
>>
>> Hi,
>>
>> I've a couple of questions regarding the ongoing work on Neutron Group
>> Policy proposed in [1].
>>
>> 1. One of the described actions is redirection to a service chain. How do
>> you see BPs [2] and [3] addressing service chaining? Will this BP implement
>> its own service chaining mechanism enforcing traffic steering or will it
>> make use of, and thus depending on, those BPs?
>
>
>     We plan to support both specifying Neutron "native" service chain
> (reference [2] from your email below) as the object to 'redirect' traffic to
> as well as actually setting an ordered chain of services specified directly
> via the 'redirect' list. In the latter case we would need the plugins to
> perform traffic steering across these services.
>
>
>> 2. In the second use case presented in the BP document, "Tired application
>> with service insertion/chaining", do you consider that the two firewalls
>> entities can represent the same firewall instance or two running and
>> independent instances? In case it's a shared instance, how would it support
>> multiple chains? This is, HTTP(s) traffic from Inet group would be
>> redirected to the firewall and then passes through the ADC; traffic from App
>> group with destination DB group would also be redirected to the very same
>> firewall instance, although to a different destination group as the chain
>> differs.
>
>
>     We certainly do not restrict users from setting the same firewall
> instance on two different 'redirect' list - but at this point, since the
> group-policy project has no plan to perform actual configurations for the
> services, it is therefore the users' responsibility to set the rules
> correctly on the firewall instance such that the correct firewall rules will
> be applied for traffic from group A -> B as well as group C -> D.
>
> - Stephen
>
>>
>>
>> Thanks.
>>
>> Cheers,
>> Carlos Gonçalves
>>
>> [1]
>> https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
>> [2]
>> https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering
>> [3]
>> https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>