[openstack-dev] [neutron][policy] Integrating network policies and network services
Mohammad Banikazemi
mb at us.ibm.com
Mon Mar 17 19:03:50 UTC 2014
I think there are a couple of issues here:
1- Having network services in VMs: There was a design summit session in
this regard in Hong Kong: Framework for Advanced Services in VMs [1]. There
is a corresponding blueprint [2] and some code submitted for early review
marked as work in progress [3]. We should follow up on this work and see
its status and what the plans for near future are. This seems to be
increasingly more relevant and more important.
2- Is it worth revisiting the requirement for having service chain types
specific to particular chains of services? The argument I have heard for
the current design is that the set of chains that are practically used are
very limited. Furthermore, having generic service type chain drivers may be
difficult to develop. With respect to limited use cases, I think even if
that is the case right now, we may be pushing ourselves into a corner as
more diverse set of network services and functions become available (as
suggested by Carlos). So I think the real question is are there practical
barriers in developing a more generic service type for service chains.
Best,
-Mohammad
[1]
http://icehousedesignsummit.sched.org/event/1deb4de716730ca7cecf0c3b968bc592
[2] https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms
[3] https://review.openstack.org/#/c/72068/
From: Kanzhe Jiang <kanzhe.jiang at bigswitch.com>
To: "OpenStack Development Mailing List (not for usage questions)"
<openstack-dev at lists.openstack.org>,
Date: 03/17/2014 12:54 PM
Subject: Re: [openstack-dev] [neutron][policy] Integrating network
policies and network services
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_______________________________________________
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/20140317/1a9ebdf4/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140317/1a9ebdf4/attachment.gif>
More information about the OpenStack-dev
mailing list
