Open Stack

Hi
Please see inline ....


On Sun, Dec 15, 2013 at 8:49 AM, Stephen Wong <s3wong at midokura.com> wrote:

> 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:
>
>
Or should this be a query the plugin for supported actions and thus the
user knows what functionality the plugin can support.  Hence there is no
default supported list.

        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)
>
>
I am not sure making the UUIDs a list of neutron objects or endpoints will
work well. It seems that it should more higher level such as list of
services that form a chain. Lets say one forms a chain of services,
firewall, IPS, LB. It would be tough to expect user to derive the neutron
ports create a chain of them. It could be a VM UUID.

    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"
>
>
As I said above one needs clarity on what these UUIDs mean. Also do we need
a call to manage the ordered list around adding, deleting.listing the
elements in the list.
One other issue that comes up whether the classifier holds up along the
chain. The classifier that goes into the chain might not be the same on the
reverse path.

    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.
>
>
We do need to support various use cases mentioned in the document where the
classifier is required to match on various fields in the packet header such
as IP address, MAC address, ports etc. The use cases are L2 firewall,
Monitoring devices where the traffic being sent to them is not dependent on
where they come from, thus can be derived from src and dst groups.


> 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 at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131216/89b0e37d/attachment.html>