Hi, During Thursday's group-policy meeting[1], there are several policy-rules related issues which we agreed should be posted on the mailing list to gather community comments / consensus. They are:
(1) Conflict resolution between policy-rules --- a priority field was added to the policy-rules attributes list[2]. Is this enough to resolve conflict across policy-rules (or even across policies)? Please state cases where a cross policy-rules conflict can occur. --- conflict resolution was a major discussion point during Thursday's meeting - and there was even suggestion on setting priority on endpoint groups; but I would like to have this email thread focused on conflict resolution across policy-rules in a single policy first. (2) Default policy-rule actions --- there seems to be consensus from the community that we need to establish some basic set of policy-rule actions upon which all plugins/drivers would have to support --- just to get the discussion going, I am proposing: a.) action_type: 'security' action: 'allow' | 'drop' b.) action_type: 'qos' action: {'qos_class': {'critical' | 'low-priority' | 'high-priority' | 'low-immediate' | 'high-immediate' | 'expedite-forwarding'} (a subset of DSCP values - hopefully in language that can be well understood by those performing application deployments) c.) action_type:'redirect' action: {UUID, [UUID]...} (a list of Neutron objects to redirect to, and the list should contain at least one element) Please discuss. In the document, there is also 'rate-limit' and 'policing' for 'qos' type, but those can be optional instead of required for now (3) Prasad asked for clarification on 'redirect' action, I propose to add the following text to document regarding 'redirect' action: "'redirect' action is used to mirror traffic to other destinations - destination can be another endpoint group, a service chain, a port, or a network. Note that 'redirect' action type can be used with other forwarding related action type such as 'security'; therefore, it is entirely possible that one can specify {'security':'deny'} and still do {'redirect':{'uuid-1', 'uuid-2'...}. Note that the destination specified on the list CANNOT be the endpoint-group who provides this policy. Also, in case of destination being another endpoint-group, the policy of this new destination endpoint-group will still be applied" Please discuss. (4) We didn't get a chance to discuss this during last Thursday's meeting, but there has been discussion on the document regarding adding IP address fields in the classifier of a policy-rule. Email may be a better forum to state the use cases. Please discuss here. I will gather all the feedback by Wednesday and update the document before this coming Thursday's meeting. Thanks, - Stephen [1] http://eavesdrop.openstack.org/meetings/networking_policy/2013/networking_policy.2013-12-12-16.01.log.html [2] https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.x1h06xqhlo1n _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev