Open Stack

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