Open Stack

Hi Carlos,

The provider mechanism is currently under discussion in advanced service
group. However, your use-case of chaining non-neutron service has not been
considered in the proposal. If you believe it is an important feature,
please definitely be vocal, even better to have a proposal. :-)


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.
>
>
> I'm partially with Mohammad on this.
>
> For what I've understood from the service chaining proposal, there would
> be different service chain provider implementations with each one
> restricting to a statically defined and limited number of services for
> chaining (please correct me if I'm mistaken). This is, and taking the
> "Firewall-VPN-ref-Chain" service chain provider from the document as
> example, users would be limited to creating chains "firewall -> VPN" (and
> I'm not even considering the restrictiveness of service providers) but not
> "VPN -> firewall", or introducing a LB in the middle.
>


>
> My rough understanding on chaining, in a broad term, would be to firstly
> support generic L2/L3 chaining, and not restricting to Neutron services
> (FWaaS, LBaaS, VPNaaS) if that is the case, but should also be valid for
> them as they can be reached via network ports as well.
>
> Last week during the advanced services meeting I presented the following
> use case. DPI (Deep Packet Inspection) is an example of a absent Neutron
> service as of now. Users wanting to run a DPI instance in OpenStack would
> have to create a virtual machine and run it there which is fine. Now, in
> case they want to filter inbound traffic from a (public) network, traffic
> should be steered first to the VM running the DPI and then to the final
> destination. Currently in OpenStack it is not possible to configure this
> and I don't see how in the proposed BP it would be. It was given the
> example of a DPI, but it can be virtually any service type and service
> implementation. Sure users wouldn't get all the fancy APIs OpenStack
> providers instantiate and configure services.
>
>




-- 
Kanzhe Jiang
MTS at BigSwitch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/23ba18d6/attachment.html>