Open Stack

On Tue, Dec 17, 2013 at 7:34 PM, Stephen Wong <s3wong at 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.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.
> >>
> >> (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 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.
>
> Hmm. What does a list of UUIDs mean. Copy the traffic to all UUID
endpoints that match the classifier?

> 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 at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131219/3f41bf19/attachment.html>