<html><body>
<p><font size="2" face="sans-serif">I think there are a couple of issues here:</font><br>
<br>
<font size="2" face="sans-serif">1- Having network services in VMs: There was a design summit session in this regard in Hong Kong: Framework for Advanced Services in VMs </font><font size="2" face="sans-serif">[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. </font><br>
<br>
<font size="2" face="sans-serif">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.</font><br>
<br>
<font size="2" face="sans-serif">Best,</font><br>
<br>
<font size="2" face="sans-serif">-Mohammad</font><br>
<br>
<br>
<font size="2" face="sans-serif">[1] <a href="http://icehousedesignsummit.sched.org/event/1deb4de716730ca7cecf0c3b968bc592">http://icehousedesignsummit.sched.org/event/1deb4de716730ca7cecf0c3b968bc592</a></font><br>
<font size="2" face="sans-serif">[2] <a href="https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms">https://blueprints.launchpad.net/neutron/+spec/adv-services-in-vms</a></font><br>
<font size="2" face="sans-serif">[3] <a href="https://review.openstack.org/#/c/72068/">https://review.openstack.org/#/c/72068/</a></font><br>
<br>
<img width="16" height="16" src="cid:1__=0ABBF60DDFF5263D8f9e8a93df938@us.ibm.com" border="0" alt="Inactive hide details for Kanzhe Jiang ---03/17/2014 12:54:52 PM---Hi Carlos, The provider mechanism is currently under discuss"><font size="2" color="#424282" face="sans-serif">Kanzhe Jiang ---03/17/2014 12:54:52 PM---Hi Carlos, The provider mechanism is currently under discussion in advanced service</font><br>
<br>
<font size="1" color="#5F5F5F" face="sans-serif">From: </font><font size="1" face="sans-serif">Kanzhe Jiang <kanzhe.jiang@bigswitch.com></font><br>
<font size="1" color="#5F5F5F" face="sans-serif">To: </font><font size="1" face="sans-serif">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org>, </font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Date: </font><font size="1" face="sans-serif">03/17/2014 12:54 PM</font><br>
<font size="1" color="#5F5F5F" face="sans-serif">Subject: </font><font size="1" face="sans-serif">Re: [openstack-dev] [neutron][policy] Integrating network policies and network services</font><br>
<hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br>
<br>
<br>
<br>
<font size="3" face="serif">Hi Carlos,</font><br>
<br>
<font size="3" face="serif">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. :-)<br>
</font><br>
<ul style="padding-left: 55pt"><font size="1" face="sans-serif">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? </font><font size="1" face="Helvetica"><br>
</font></ul>
<ul style="padding-left: 45pt"><font size="1" face="Helvetica">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. </font></ul>
<ul style="padding-left: 9pt"><br>
<font size="3" face="serif">I’m partially with Mohammad on this.</font><br>
<br>
<font size="3" face="serif">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.</font></ul>
<font size="3" face="serif"> </font>
<ul style="padding-left: 9pt"><br>
<font size="3" face="serif">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.</font><br>
<br>
<font size="3" face="serif">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.</font><br>
</ul>
<br>
<br>
<font size="3" face="serif"><br>
</font><br>
<br>
<font size="3" face="serif">-- <br>
Kanzhe Jiang</font><br>
<font size="3" face="serif">MTS at BigSwitch</font><tt><font size="2">_______________________________________________<br>
OpenStack-dev mailing list<br>
OpenStack-dev@lists.openstack.org<br>
</font></tt><tt><font size="2"><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></font></tt><tt><font size="2"><br>
</font></tt><br>
</body></html>