<div dir="ltr">Hi Carlos,<div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 12, 2014 at 9:37 AM, Carlos Gonçalves <span dir="ltr"><<a href="mailto:mail@cgoncalves.pt" target="_blank">mail@cgoncalves.pt</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Hi,<div><br></div><div>I’ve a couple of questions regarding the ongoing work on Neutron Group Policy proposed in [1].</div>
<div><br></div><div>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?</div>
</div></blockquote><div><br></div><div>    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.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div>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.<br>
</div></div></blockquote><div><br></div><div>    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.</div>
<div><br></div><div>- Stephen</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div></div><div><br></div><div>Thanks.</div>
<div><br></div><div>Cheers,</div><div>Carlos Gonçalves</div><div><br></div><div>[1] <a href="https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction" target="_blank">https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction</a></div>
<div>[2] <a href="https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering" target="_blank">https://blueprints.launchpad.net/neutron/+spec/neutron-services-insertion-chaining-steering</a></div>
<div>[3] <a href="https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation" target="_blank">https://blueprints.launchpad.net/neutron/+spec/nfv-and-network-service-chain-implementation</a></div>
<div><br></div></div><br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div></div>