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
