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