<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Dec 17, 2013 at 7:34 PM, Stephen Wong <span dir="ltr"><<a href="mailto:s3wong@midokura.com" target="_blank">s3wong@midokura.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Prasad,<br>
<br>
Thanks for the comments, please see responses inline.<br>
<div><div class="h5"><br>
On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki<br>
<<a href="mailto:prasad.vellanki@oneconvergence.com">prasad.vellanki@oneconvergence.com</a>> wrote:<br>
> Hi<br>
> Please see inline ....<br>
><br>
><br>
> On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong <<a href="mailto:s3wong@midokura.com">s3wong@midokura.com</a>> 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 priority<br>
>> on endpoint groups; but I would like to have this email thread focused<br>
>> on conflict resolution across policy-rules in a single policy first.<br>
>><br>
>> (2) Default policy-rule actions<br>
>> --- there seems to be consensus from the community that we need 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 the user<br>
> knows what functionality the plugin can support. Hence there is no default<br>
> supported list.<br>
<br>
</div></div> 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></blockquote><div><br></div><div>I agree that we should simplify this for POC.</div><div><br></div><div>The use case is in the UI the user should know what actions are valid. The user should not wait for error to figure out whether a action is valid. But if we put well defined set that is mandatory this is not an issue. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><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 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 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 neutron<br>
> ports create a chain of them. It could be a VM UUID.<br>
<br>
</div> Service chain is a Neutron object with UUID:<br>
<br>
<a href="https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#" target="_blank">https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#</a><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>
<div class="im"><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 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, 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 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 the<br>
> chain. The classifier that goes into the chain might not be the same on the<br>
> reverse path.<br>
<br>
</div> 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></blockquote><div>Hmm. What does a list of UUIDs mean. Copy the traffic to all UUID endpoints that match the classifier? </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks,<br>
- Stephen<br>
<div class="HOEnZb"><div class="h5"><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 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 where the<br>
> classifier is required to match on various fields in the packet header 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 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>
>> <a href="http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html" target="_blank">http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html</a><br>
>> [2]<br>
>> <a href="https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n" target="_blank">https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n</a><br>
>><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>
><br>
><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>
<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>
</div></div></blockquote></div><br></div></div>