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 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.
We should try to leave open the option of having a single UUID in a
redirect action that could point to a named service chain (as defined
elsewhere), or alternatively, using the list of UUIDs to define the
service chain directly in the policy (where they could reference a VM,
network, etc.). This would require that the list of UUIDs implies an
ordering (which is what I thought we were doing, but seems there are
differing views on that).
Also the word "mirroring" confused me here ... the redirect shouldn't be a
mirroring action -- we could define an additional action_type to mirror
traffic, however.
I agree that the classifier can be different in forward and reverse
direction, hence the proposal to have policies explicitly define a
source/dest so you would have one for each direction.
thanks.
-- Anees
>
> 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 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
> >
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
<<inline: graycol.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
