<html><body>
<p><font size="2" face="sans-serif">Please have a look at the agenda for tomorrow at <a href="https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy">https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy</a></font><br>
<font size="2" face="sans-serif">It would be great if we could at least close on the following two items tomorrow:</font><br>
<br>
<font size="4" color="#2F2F2F" face="ArialUnicodeMS"> 1. Converged model by allowing policies to have a destination group and a source group. Each of these groups can have one or more end points.</font><br>
<font size="4" color="#2F2F2F" face="ArialUnicodeMS"> 2. Minimum set of actions to support: security, redirect, (and possibly qos)</font><br>
<br>
<font size="2" face="sans-serif">We don't need to be perfect and we can always revisit but if we agree on these we can start thinking about a PoC implementation which itself may lead to more design issues that we will need to consider and discuss.</font><br>
<br>
<font size="2" face="sans-serif">Based on the discussions we have had, other items that we need to discuss include the conflict resolution and also the capability to query a plugin for supported actions.</font><br>
<br>
<font size="2" face="sans-serif">Mohammad</font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF6D5DF8657B48f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Anees A Shaikh---12/18/2013 08:02:52 PM---folks, sorry for the late input ... a few additional though"><font size="2" color="#424282" face="sans-serif">Anees A Shaikh---12/18/2013 08:02:52 PM---folks, sorry for the late input ... a few additional thoughts... > Hi Prasad,</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Anees A Shaikh/Watson/IBM@IBMUS</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">Stephen Wong <s3wong@midokura.com>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Cc: </font><font size="1" face="sans-serif">openstack-dev@lists.openstack.org</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">12/18/2013 08:02 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<tt><font size="2">folks, sorry for the late input ... a few additional thoughts...<br>
<br>
> Hi Prasad,<br>
> <br>
> Thanks for the comments, please see responses inline.<br>
> <br>
> On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki<br>
> <prasad.vellanki at oneconvergence.com> wrote:<br>
> > Hi<br>
> > Please see inline ....<br>
> ><br>
> ><br>
> > On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong <s3wong at <br>
> midokura.com> wrote:<br>
> >><br>
> >> Hi,<br>
> >><br>
> >> During Thursday's group-policy meeting[1], there are several<br>
> >> policy-rules related issues which we agreed should be posted on the<br>
> >> mailing list to gather community comments / consensus. They are:<br>
> >><br>
> >> (1) Conflict resolution between policy-rules<br>
> >> --- a priority field was added to the policy-rules attributes<br>
> >> list[2]. Is this enough to resolve conflict across policy-rules (or<br>
> >> even across policies)? Please state cases where a cross policy-rules<br>
> >> conflict can occur.<br>
> >> --- conflict resolution was a major discussion point during<br>
> >> Thursday's meeting - and there was even suggestion on setting <br>
priority<br>
> >> on endpoint groups; but I would like to have this email thread <br>
focused<br>
> >> on conflict resolution across policy-rules in a single policy first.<br>
<br>
I agree with keeping the focus on intra-policy conflicts and even there <br>
would suggest we try to keep things dead simple to start at the expense of <br>
some flexibility in handling every use case. This is a classic problem in <br>
policy frameworks and I hope we don't grind to a halt trying to address <br>
it.<br>
<br>
> >><br>
> >> (2) Default policy-rule actions<br>
> >> --- there seems to be consensus from the community that we need <br>
to<br>
> >> establish some basic set of policy-rule actions upon which all<br>
> >> plugins/drivers would have to support<br>
> >> --- just to get the discussion going, I am proposing:<br>
> >><br>
> ><br>
> > Or should this be a query the plugin for supported actions and thus <br>
the user<br>
> > knows what functionality the plugin can support. Hence there is no <br>
default<br>
> > supported list.<br>
> <br>
> I think what we want is a set of "must-have" actions which<br>
> application can utilize by default while using the group-policy APIs.<br>
> Without this, application would need to perform many run time checks<br>
> and have unpredictable behavior across different deployments.<br>
> <br>
> As for querying for a capability list - I am not against having<br>
> such API, but what is the common use case? Having a script querying<br>
> for the supported action list and generate policies based on that?<br>
> Should we expect policy definition to be so dynamic?<br>
<br>
My view is that the query capability may be where we try to go eventually, <br>
but we should start with a must-have list that is very small, e.g., just <br>
the security policy. Other action types would be optional but <br>
well-defined.<br>
<br>
<br>
> <br>
> ><br>
> >> a.) action_type: 'security' action: 'allow' | 'drop'<br>
> >> b.) action_type: 'qos' action: {'qos_class': {'critical' |<br>
> >> 'low-priority' | 'high-priority' |<br>
> >><br>
> >> 'low-immediate' | 'high-immediate' |<br>
> >><br>
> >> 'expedite-forwarding'}<br>
> >> (a subset of DSCP values - hopefully in language that <br>
can<br>
> >> be well understood by those performing application deployments)<br>
> >> c.) action_type:'redirect' action: {UUID, [UUID]...}<br>
> >> (a list of Neutron objects to redirect to, and the list<br>
> >> should contain at least one element)<br>
> >><br>
> ><br>
> > I am not sure making the UUIDs a list of neutron objects or endpoints <br>
will<br>
> > work well. It seems that it should more higher level such as list of<br>
> > services that form a chain. Lets say one forms a chain of services,<br>
> > firewall, IPS, LB. It would be tough to expect user to derive the <br>
neutron<br>
> > ports create a chain of them. It could be a VM UUID.<br>
> <br>
> Service chain is a Neutron object with UUID:<br>
> <br>
> </font></tt><tt><font size="2"><a href="https://docs.google.com/document/d/">https://docs.google.com/document/d/</a></font></tt><tt><font size="2"><br>
> 1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#<br>
> <br>
> so this is not defined by the group-policy subgroup, but from a<br>
> different project. We expect operator / tenant to define a service<br>
> chain for the users, and users simply pick that as one of the<br>
> "redirect action" object to send traffic to.<br>
> <br>
> ><br>
> >> Please discuss. In the document, there is also 'rate-limit' and<br>
> >> 'policing' for 'qos' type, but those can be optional instead of<br>
> >> required for now<br>
> >><br>
> >> (3) Prasad asked for clarification on 'redirect' action, I propose to<br>
> >> add the following text to document regarding 'redirect' action:<br>
> >><br>
> >> "'redirect' action is used to mirror traffic to other <br>
destinations<br>
> >> - destination can be another endpoint group, a service chain, a port,<br>
> >> or a network. Note that 'redirect' action type can be used with other<br>
> >> forwarding related action type such as 'security'; therefore, it is<br>
> >> entirely possible that one can specify {'security':'deny'} and still<br>
> >> do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination<br>
> >> specified on the list CANNOT be the endpoint-group who provides this<br>
> >> policy. Also, in case of destination being another endpoint-group, <br>
the<br>
> >> policy of this new destination endpoint-group will still be applied"<br>
> >><br>
> ><br>
> > As I said above one needs clarity on what these UUIDs mean. Also do we <br>
need<br>
> > a call to manage the ordered list around adding, deleting.listing the<br>
> > elements in the list.<br>
> > One other issue that comes up whether the classifier holds up along <br>
the<br>
> > chain. The classifier that goes into the chain might not be the same <br>
on the<br>
> > reverse path.<br>
> <br>
> The redirect list does not define a service chain, a service chain<br>
> is defined via other Neutron APIs. The redirect list itself is not<br>
> order sensitive.<br>
<br>
We should try to leave open the option of having a single UUID in a <br>
redirect action that could point to a named service chain (as defined <br>
elsewhere), or alternatively, using the list of UUIDs to define the <br>
service chain directly in the policy (where they could reference a VM, <br>
network, etc.). This would require that the list of UUIDs implies an <br>
ordering (which is what I thought we were doing, but seems there are <br>
differing views on that). <br>
<br>
Also the word "mirroring" confused me here ... the redirect shouldn't be a <br>
mirroring action -- we could define an additional action_type to mirror <br>
traffic, however.<br>
<br>
I agree that the classifier can be different in forward and reverse <br>
direction, hence the proposal to have policies explicitly define a <br>
source/dest so you would have one for each direction.<br>
<br>
thanks.<br>
-- Anees<br>
<br>
<br>
> <br>
> Thanks,<br>
> - Stephen<br>
> <br>
> ><br>
> >> Please discuss.<br>
> >><br>
> >> (4) We didn't get a chance to discuss this during last Thursday's<br>
> >> meeting, but there has been discussion on the document regarding<br>
> >> adding IP address fields in the classifier of a policy-rule. Email <br>
may<br>
> >> be a better forum to state the use cases. Please discuss here.<br>
> >><br>
> >> I will gather all the feedback by Wednesday and update the<br>
> >> document before this coming Thursday's meeting.<br>
> >><br>
> ><br>
> > We do need to support various use cases mentioned in the document <br>
where the<br>
> > classifier is required to match on various fields in the packet header <br>
such<br>
> > as IP address, MAC address, ports etc. The use cases are L2 firewall,<br>
> > Monitoring devices where the traffic being sent to them is not <br>
dependent on<br>
> > where they come from, thus can be derived from src and dst groups.<br>
> ><br>
> >><br>
> >> Thanks,<br>
> >> - Stephen<br>
> >><br>
> >> [1]<br>
> >> </font></tt><tt><font size="2"><a href="http://eavesdrop.openstack.org/meetings/networking_policy/2013/">http://eavesdrop.openstack.org/meetings/networking_policy/2013/</a></font></tt><tt><font size="2"><br>
> networking_policy.2013-12-12-16.01.log.html<br>
> >> [2]<br>
> >> </font></tt><tt><font size="2"><a href="https://docs.google.com/document/d/">https://docs.google.com/document/d/</a></font></tt><tt><font size="2"><br>
> 1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n<br>
> >><br>
> >> _______________________________________________<br>
> >> OpenStack-dev mailing list<br>
> >> OpenStack-dev at lists.openstack.org<br>
> >> </font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
> ><br>
<br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
<br>
</font></tt><br>
</body></html>