<div dir="ltr">This proposal Looks like more flexible for the network traffic security. For current FW V2, we support  2 security levels for a single Neutron port. One is security group, the other is firewall group,  but this looks like support more. And the firewall depolyer/dispatcher need to own some network knowledge for configuring the specific fw rule. So it's necessary to provide a good user experience, like security tags or some thing.</div><div class="gmail_extra"><br><div class="gmail_quote">2018-05-11 1:03 GMT+08:00 Miguel Lavalle <span dir="ltr"><<a href="mailto:miguel@mlavalle.com" target="_blank">miguel@mlavalle.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div>Hi,<br><br></div>As discussed during the weekly FWaaS IRC meeting, there is a new proposal for the evolution of the FWaaS API here:  <a href="https://docs.google.com/document/d/1lnzV6pv841pX43sM76gF3aZ7jceRH3FPbKaGpPumWgs/edit" target="_blank">https://docs.google.com/<wbr>document/d/<wbr>1lnzV6pv841pX43sM76gF3aZ7jceRH<wbr>3FPbKaGpPumWgs/edit</a><br><br></div>This proposal is based on the current FWaaS V2.0 API as documented here: <a href="https://specs.openstack.org/openstack/neutron-specs/specs/mitaka/fwaas-api-2.0.html" target="_blank">https://specs.openstack.org/<wbr>openstack/neutron-specs/specs/<wbr>mitaka/fwaas-api-2.0.html</a>. The key additional features proposed are:<br><ol><li>Firewall groups not only associate with ports but also with subnets, other firewall groups and dynamic rules. A list of excluded ports can be specified<br></li><li>Dynamic rules make possible the association with Nova instances by security tags and VM names</li><li>Source and destination address groups can be lists</li><li>A re-direct action in firewall rules</li><li>Priority attribute in firewall policies</li><li>A default rule resource</li></ol><p>The agreement in the meeting was for the team to help identify the areas where there is incremental features in the proposal compared to what is currently in place plus the what is being already planned for implementation. A spec will be developed based on that increment. We will meet in Vancouver to continue the conversation face to face</p><p>Best regards</p><span class="HOEnZb"><font color="#888888"><p>Miguel<br></p></font></span></div>
<br>______________________________<wbr>______________________________<wbr>______________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.<wbr>openstack.org?subject:<wbr>unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>openstack-dev</a><br>
<br></blockquote></div><br></div>