[openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

Prasad Vellanki prasad.vellanki at oneconvergence.com
Thu Dec 19 08:59:12 UTC 2013


On Dec 17, 2013 3:22 PM, "Tim Hinrichs" <thinrichs at vmware.com> wrote:
>
>
>
> ----- Original Message -----
> | From: "Prasad Vellanki" <prasad.vellanki at oneconvergence.com>
> | To: "OpenStack Development Mailing List (not for usage questions)" <
openstack-dev at lists.openstack.org>
> | Sent: Monday, December 16, 2013 2:11:37 PM
> | Subject: Re: [openstack-dev] [neutron][policy] Policy-Rules discussions
based on Dec.12 network policy meeting
> |
> |
> |
> | 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.
> |
>
> There was interest in having a single policy that could include different
actions so that a single flow might be both redirected and QOSed
simultaneously.  For me this rules out a total ordering on the policy
statements.  Here's a proposal that relies on the fact that we're fixing
the meaning of actions within the language: the language specifies a
partial order on the *actions*.  For example, DENY takes precedence over
ALLOW, so if we both ALLOW and DENY, then the conflict resolution dictates
DENY wins. But {DENY, ALLOW} and QOS and REDIRECT are all unrelated, so
there is no problem with a policy that both DENYs and QOSes and REDIRECTs.
>
> | (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.
> |
>
> I think the important part is that the language defines what the actions
mean.  Whether each plugin supports them all is a different issue.  If the
language doesn't define the meaning of the actions, there's no way for
anyone to use the language.  We might be able to write down policies, but
we don't know what those policies actually mean because 2 plugins might
assign very different meanings to the same action name.
>

I agree that it is very important to define what actions mean.


As for supported action, it is probably best to simplify this for POC by
restricting it to a small set of actions. One can always add this call. My
point was UI becomes cleaner and clear for the user if you have the call.


> |
> |
> | 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.
> |
> |
>
> Perhaps we could use our usual group mechanism here and say that the
redirect action operates on 3 groups: source, destination, and the group to
which we want to redirect.

>
> |
> | 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
> |
>
> It would be nice if we had some rationale for deciding which actions to
include and which to leave out.  Maybe if we found a
standard/spec/collection-of-use-cases and included exactly the same
actions.  Or if we go with the action-based conflict resolution scheme from
(1), we might want to think about whether we have at least complementary
actions (e.g. ALLOW and DENY, WAYPOINT -- route traffic through a group of
middleboxes-- and FORBID -- prohibit traffic from passing through
middleboxes).
>
> | (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"
>
> Are you saying we are replicating traffic and routing one version to a
different destination, or are we simply changing the destination of the
original traffic?  What if we wanted to route the traffic through an
intermediary but arrive at the same destination?  Would waypointing be a
separate action?
>
> |
> |
> |
> |
> | 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.
>
> I think those UUIDs need to be neutron objects; otherwise, I don't see
how Neutron could hope to execute the action.
>

I agree that UUID need to eb Neutron object or something well defined that
such as a VM which neutron knows. But I think it is best to use service or
service chain object defined by services extension api for this.
> |
> |
> |
> | 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.
> |
>
> Agreed.  Maybe we could take an existing spec like OpenFlow and use the
same field-matches they do.
>
> Tim
>
> |
> | 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
> |
> |
> | _______________________________________________
> | OpenStack-dev mailing list
> | OpenStack-dev at lists.openstack.org
> |
https://urldefense.proofpoint.com/v1/url?u=http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev&k=oIvRg1%2BdGAgOoM1BIlLLqw%3D%3D%0A&r=%2FZ35AkRhp2kCW4Q3MPeE%2BxY2bqaf%2FKm29ZfiqAKXxeo%3D%0A&m=y9iGJQb8zdUD0oeiHlpVItErJm1yP0njx4cmoK9NJB8%3D%0A&s=322effe4ff5879643768ac6938ca88e8437ce057ee9043f9edbb6bf7f59ac140
> |
>
> _______________________________________________
> 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/20131219/a53de302/attachment.html>


More information about the OpenStack-dev mailing list