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

2013-12-19 Thread Prasad Vellanki
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

2013-12-19 Thread Prasad Vellanki
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

2013-12-18 Thread Anees A Shaikh
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

2013-12-18 Thread Mohammad Banikazemi

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

2013-12-17 Thread Tim Hinrichs


- 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

2013-12-17 Thread Stephen Wong
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

2013-12-17 Thread Stephen Wong
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 

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

2013-12-15 Thread Subrahmanyam Ongole
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