Open Stack

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>