[openstack-dev] [neutron][policy] Policy-Rules discussions based on Dec.12 network policy meeting

Stephen Wong s3wong at midokura.com
Wed Dec 18 02:52:15 UTC 2013

Hi Subra,

On Sun, Dec 15, 2013 at 9:32 PM, Subrahmanyam Ongole <osms69 at gmail.com> wrote:
> Hi Stephan
> Comments inline for redirect action. Perhaps we may want to discuss each
> section in different email threads.
> 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:
>> (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"
>>     Please discuss.
> a. In Neutron, I am not sure whether there is a way to get an object given a
> UUID without knowing the type of the object, be it a port, network or a
> specific type of Neutron service.
> I am less likely to err if uuid is qualified by a type or some human
> readable name.

    Excellent point. I will add a type field for each redirect object.
Thanks for pointing it out.

> b. Is chain definition (how you build a chain of services) within the scope
> of Global policy BP? A chain may need to be more than an ordered list of
> UUIDs. It needs be a graph with branches anywhere in the chain.  Each path
> could be considered as a separate chain as well.

    Service chain as defined by the following:


    which is a Neutron object (service_graph is encapsulated inside
this object; see service_chain resource).

- Stephen

> Thanks
> Subra
>>     I will gather all the feedback by Wednesday and update the
>> document before this coming Thursday's meeting.
>> 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

More information about the OpenStack-dev mailing list