Open Stack

On Wed, Mar 19, 2014 at 12:23 PM, Louis.Fourie <Louis.Fourie at huawei.com>wrote:

>  Mohammad,
>
>   Agree, the information models for these two proposals are very similar.
>
>
>
> It appears that the ODL model offers some additional flexibility in that
> direction attributes are
>
> attached to Classifiers and Directives rather than Policies in the
> Openstack model.
>
>
>
> Maybe the authors can comment on other differences and their motivation?
>
>
>
> Is there any plan to merge these two models and create a common model?  Is
> there a group
>
> within OpenStack actively working on this?  Will this work be done within
> OpenStack or OpenDaylight?
>
>
>
Yes, we've been having weekly meetings since the Hong Kong Summit on this
[1]. Please join us
on IRC if you want. The two models are meant to be pretty much the same,
though the ODL models
are expanded a bit compared to the Neutron models at the moment.

Thanks,
Kyle

[1] https://wiki.openstack.org/wiki/Meetings/Neutron_Group_Policy

>  -          Louis
>
>
>
> *From:* Mohammad Banikazemi [mailto:mb at us.ibm.com]
> *Sent:* Tuesday, March 18, 2014 9:20 PM
>
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Cc:* OpenStack Development Mailing List (not for usage questions)
>
> *Subject:* Re: [openstack-dev] [neutron][policy] Integrating network
> policies and network services
>
>
>
> Louis, We are still working on the details of the new contract based
> model. To get an idea please refer to the original project google document
> [1] and look under the section titled
> *Use Cases: **3-tier Application with Security Policies *where policies
> are described through a provider/consumer relationship. The contract model
> is similar to the model being worked out by a similarly named project in
> OpenDaylight. You can find more information on the contract model there [2].
>
> Best,
>
> Mohammad
>
>
> [1]
> https://docs.google.com/document/d/1ZbOFxAoibZbJmDWx1oOrOsDcov6Cuom5aaBIrupCD9E/edit#heading=h.gebyoou6khks
> [2]
> https://wiki.opendaylight.org/view/Project_Proposals:Application_Policy_Plugin
>
> [image: Inactive hide details for "Louis.Fourie" ---03/18/2014 03:23:05
> PM---Mohammad, Can you share details on the contract-based po]"Louis.Fourie"
> ---03/18/2014 03:23:05 PM---Mohammad,   Can you share details on the
> contract-based policy model?
>
> From: "Louis.Fourie" <Louis.Fourie at huawei.com>
> To: "OpenStack Development Mailing List (not for usage questions)" <
> openstack-dev at lists.openstack.org>,
> Date: 03/18/2014 03:23 PM
> Subject: Re: [openstack-dev] [neutron][policy] Integrating network
> policies and network services
>  ------------------------------
>
>
>
>
> Mohammad,
>   Can you share details on the contract-based policy model?
>
> -          Louis
>
>
> *From:* Mohammad Banikazemi [mailto:mb at us.ibm.com <mb at us.ibm.com>]
> * Sent:* Friday, March 14, 2014 3:18 PM
> * To:* OpenStack Development Mailing List (not for usage questions)
> * Subject:* [openstack-dev] [neutron][policy] Integrating network
> policies and network services
>
>
> We have started looking at how the Neutron advanced services being defined
> and developed right now can be used within the Neutron policy framework we
> are building. Furthermore, we have been looking at a new model for the
> policy framework as of the past couple of weeks. So, I have been trying to
> see how the services will fit in (or can be utilized by) the policy work in
> general and with the new contract-based model we are considering in
> particular. Some of the I like to discuss here are specific to the use of
> service chains with the group policy work but some are generic and related
> to service chaining itself.
>
> If I understand it correctly, the proposed service chaining model requires
> the creation of the services in the chain without specifying their
> insertion contexts. Then, the service chain is created with specifying the
> services in the chain, a particular provider (which is specific to the
> chain being built) and possibly source and destination insertion contexts.
>
> 1- This fits ok with the policy model we had developed earlier where the
> policy would get defined between a source and a destination policy endpoint
> group. The chain could be instantiated at the time the policy gets defined.
> (More questions on the instantiation below marked as 1.a and 1.b.) How
> would that work in a contract based model for policy? At the time a
> contract is defined, it's producers and consumers are not defined yet.
> Would we postpone the instantiation of the service chain to the time a
> contract gets a producer and at least a consumer?
>
> 1.a- It seems to me, it would be helpful if not necessary to be able to
> define a chain without instantiating the chain. If I understand it
> correctly, in the current service chaining model, when the chain is
> created, the source/destination contexts are used (whether they are
> specified explicitly or implicitly) and the chain of services become
> operational. We may want to be able to define the chain and postpone its
> creation to a later point in time.
>
> 1.b-Is it really possible to stand up a service without knowing its
> insertion context (explicitly defined or implicitly defined) in all cases?
> For certain cases this will be ok but for others, depending on the
> insertion context or other factors such as the requirements of other
> services in the chain we may need to for example instantiate the service
> (e.g. create a VM) at a specific location that is not known when the
> service is created. If that may be the case, would it make sense to not
> instantiate the services of a chain at any level (rather than instantiating
> them and mark them as not operational or not routing traffic to them)
> before the chain is created? (This leads to question 3 below.)
>
> 2- With one producer and multiple consumers, do we instantiate a chain
> (meaning the chain and the services in the chain become operational) for
> each consumer? If not, how do we deal with using the same
> source/destination insertion context pair for the provider and all of the
> consumers?
>
> 3- For the service chain creation, I am sure there are good reasons for
> requiring a specific provider for a given chain of services but wouldn't it
> be possible to have a generic "chain" provider which would instantiate each
> service in the chain using the required provider for each service (e.g.,
> firewall or loadbalancer service) and with setting the insertion contexts
> for each service such that the chain gets constructed as well? I am sure I
> am ignoring some practical requirements but is it worth rethinking the
> current approach?
>
> Best,
>
> Mohammad_______________________________________________
> 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/20140319/38a56679/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140319/38a56679/attachment.gif>