Open Stack

Hi Mohammad,

Please see my comments inline.

Thanks,
Kanzhe


On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi <mb at us.ibm.com> wrote:

> 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.
>
> Yes, your understanding is mostly correct. The step of instantiating each
service in the chain is only for the DB resources. The service chain
provider orchestrates the actual service creation when the service chain is
created. The source/dest insertion contexts are required to create the
service chain.

> 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?
>
In a contract based model, we can add a state attribute to the service
chain. Once a contract is defined, a corresponding chain could be defined
without insertion contexts. The chain state is "pending". I assume the
producer and consumers can be used to derive the source and destination
insertion contexts for the chain. Once a contract gets producer and a
consumer, the chain can then be instantiated. When new consumers are added,
the chain would verify if the new context can be supported before updating
the existing contexts. If all producer and consumers are removed from a
contract, the chain provider deletes all service instances in the chain.

>
>
> 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?
>
The intent of the SC design is to support one provider and multiple
consumers via destination and source insertion contexts, respectively. The
addition of a new consumer requires an update to the source insertion
context of the chain. Of course, the chain provider will verify the
contexts to make sure they can be supported.

>
>
> 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?
>
> Service Chaining often means a form of traffic steering. Depending on how
the steering is done, the capabilities of different providers differ.
Different provider may define different context of individual service in
the chain. For example, a bump-in-the-wire service can be inserted as a
virtual wire or L3 next hop. So it will be hard to define a "generic" chain
provider.

> Best,
>
> Mohammad
>
>
> _______________________________________________
> 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/20140315/c46bc7f4/attachment.html>