Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
On Dec 17, 2013 3:22 PM, Tim Hinrichs thinri...@vmware.com wrote:
- 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.
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
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
On Tue, Dec 17, 2013 at 7:34 PM, Stephen Wong s3w...@midokura.com wrote:
Hi Prasad,
Thanks for the comments, please see responses inline.
On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
prasad.vella...@oneconvergence.com wrote:
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.
(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 what we want is a set of must-have actions which
application can utilize by default while using the group-policy APIs.
Without this, application would need to perform many run time checks
and have unpredictable behavior across different deployments.
As for querying for a capability list - I am not against having
such API, but what is the common use case? Having a script querying
for the supported action list and generate policies based on that?
Should we expect policy definition to be so dynamic?
I agree that we should simplify this for POC.
The use case is in the UI the user should know what actions are valid. The
user should not wait for error to figure out whether a action is valid. But
if we put well defined set that is mandatory this is not an issue.
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.
Service chain is a Neutron object with UUID:
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#
so this is not defined by the group-policy subgroup, but from a
different project. We expect operator / tenant to define a service
chain for the users, and users simply pick that as one of the
redirect action object to send traffic to.
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.
The
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
folks, sorry for the late input ... a few additional thoughts...
Hi Prasad,
Thanks for the comments, please see responses inline.
On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
prasad.vellanki at oneconvergence.com wrote:
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.
I agree with keeping the focus on intra-policy conflicts and even there
would suggest we try to keep things dead simple to start at the expense of
some flexibility in handling every use case. This is a classic problem in
policy frameworks and I hope we don't grind to a halt trying to address
it.
(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 what we want is a set of must-have actions which
application can utilize by default while using the group-policy APIs.
Without this, application would need to perform many run time checks
and have unpredictable behavior across different deployments.
As for querying for a capability list - I am not against having
such API, but what is the common use case? Having a script querying
for the supported action list and generate policies based on that?
Should we expect policy definition to be so dynamic?
My view is that the query capability may be where we try to go eventually,
but we should start with a must-have list that is very small, e.g., just
the security policy. Other action types would be optional but
well-defined.
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.
Service chain is a Neutron object with UUID:
https://docs.google.com/document/d/
1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#
so this is not defined by the group-policy subgroup, but from a
different project. We expect operator / tenant to define a service
chain for the users, and users simply pick that as one of the
redirect action object to send traffic to.
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
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
Please have a look at the agenda for tomorrow at
https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy
It would be great if we could at least close on the following two items
tomorrow:
1. Converged model by allowing policies to have a destination
group and
a source group. Each of these groups can have one or more end points.
2. Minimum set of actions to support: security, redirect, (and
possibly
qos)
We don't need to be perfect and we can always revisit but if we agree on
these we can start thinking about a PoC implementation which itself may
lead to more design issues that we will need to consider and discuss.
Based on the discussions we have had, other items that we need to discuss
include the conflict resolution and also the capability to query a plugin
for supported actions.
Mohammad
From: Anees A Shaikh/Watson/IBM@IBMUS
To: Stephen Wong s3w...@midokura.com,
Cc: openstack-dev@lists.openstack.org
Date: 12/18/2013 08:02 PM
Subject:Re: [openstack-dev] [neutron][policy] Policy-Rules discussions
based on Dec.12 network policy meeting
folks, sorry for the late input ... a few additional thoughts...
Hi Prasad,
Thanks for the comments, please see responses inline.
On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
prasad.vellanki at oneconvergence.com wrote:
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.
I agree with keeping the focus on intra-policy conflicts and even there
would suggest we try to keep things dead simple to start at the expense of
some flexibility in handling every use case. This is a classic problem in
policy frameworks and I hope we don't grind to a halt trying to address
it.
(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 what we want is a set of must-have actions which
application can utilize by default while using the group-policy APIs.
Without this, application would need to perform many run time checks
and have unpredictable behavior across different deployments.
As for querying for a capability list - I am not against having
such API, but what is the common use case? Having a script querying
for the supported action list and generate policies based on that?
Should we expect policy definition to be so dynamic?
My view is that the query capability may be where we try to go eventually,
but we should start with a must-have list that is very small, e.g., just
the security policy. Other action types would be optional but
well-defined.
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.
Service chain is a Neutron object with UUID:
https://docs.google.com/document/d/
1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#
so this is not defined by the group-policy subgroup, but from a
different project. We expect operator / tenant to define a service
chain
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
- 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
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
Hi Subra,
On Sun, Dec 15, 2013 at 9:32 PM, Subrahmanyam Ongole osm...@gmail.com wrote:
Hi Stephan
Comments inline for redirect action. Perhaps we may want to discuss each
section in different email threads.
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:
(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.
a. In Neutron, I am not sure whether there is a way to get an object given a
UUID without knowing the type of the object, be it a port, network or a
specific type of Neutron service.
I am less likely to err if uuid is qualified by a type or some human
readable name.
Excellent point. I will add a type field for each redirect object.
Thanks for pointing it out.
b. Is chain definition (how you build a chain of services) within the scope
of Global policy BP? A chain may need to be more than an ordered list of
UUIDs. It needs be a graph with branches anywhere in the chain. Each path
could be considered as a separate chain as well.
Service chain as defined by the following:
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#
which is a Neutron object (service_graph is encapsulated inside
this object; see service_chain resource).
Thanks,
- Stephen
Thanks
Subra
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
___
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
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
Hi Prasad,
Thanks for the comments, please see responses inline.
On Mon, Dec 16, 2013 at 2:11 PM, Prasad Vellanki
prasad.vella...@oneconvergence.com wrote:
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.
(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 what we want is a set of must-have actions which
application can utilize by default while using the group-policy APIs.
Without this, application would need to perform many run time checks
and have unpredictable behavior across different deployments.
As for querying for a capability list - I am not against having
such API, but what is the common use case? Having a script querying
for the supported action list and generate policies based on that?
Should we expect policy definition to be so dynamic?
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.
Service chain is a Neutron object with UUID:
https://docs.google.com/document/d/1fmCWpCxAN4g5txmCJVmBDt02GYew2kvyRsh0Wl3YF2U/edit#
so this is not defined by the group-policy subgroup, but from a
different project. We expect operator / tenant to define a service
chain for the users, and users simply pick that as one of the
redirect action object to send traffic to.
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.
The redirect list does not define a service chain, a service chain
is defined via other Neutron APIs. The redirect list itself is not
order sensitive.
Thanks,
- Stephen
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
[openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
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
Re: [openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting
Hi Stephan
Comments inline for redirect action. Perhaps we may want to discuss each
section in different email threads.
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:
(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.
a. In Neutron, I am not sure whether there is a way to get an object given
a UUID without knowing the type of the object, be it a port, network or a
specific type of Neutron service.
I am less likely to err if uuid is qualified by a type or some human
readable name.
b. Is chain definition (how you build a chain of services) within the scope
of Global policy BP? A chain may need to be more than an ordered list of
UUIDs. It needs be a graph with branches anywhere in the chain. Each path
could be considered as a separate chain as well.
Thanks
Subra
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
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
