Open Stack

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
> >