----- Original Message -----
| From: "Prasad Vellanki" <prasad.vella...@oneconvergence.com>
| To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev@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 < s3w...@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.
|
|
| 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.
|
|
|
| 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@lists.openstack.org
| http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
|
|
| _______________________________________________
| OpenStack-dev mailing list
| OpenStack-dev@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@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
