On Wed, Mar 19, 2014 at 12:23 PM, Louis.Fourie <louis.fou...@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:m...@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.fou...@huawei.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > openstack-dev@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:m...@us.ibm.com <m...@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@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 > >
<<inline: image001.gif>>
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev