<div dir="ltr"><br><div class="gmail_extra">Hi Carlos,</div><div class="gmail_extra"><br></div><div class="gmail_extra">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>
<br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><div><div class=""><blockquote type="cite"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;line-height:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p><font 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?<span> </span></font><br>
<br></p></blockquote><div>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.  </div>
</div></div></div></div></blockquote><br></div></div><div>I’m partially with Mohammad on this.</div><div><br></div><div>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.</div>
</div></div></blockquote><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word">
<div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div></div></blockquote><div><br></div><div><br></div></div><br><br clear="all"><div><br></div>-- <br>Kanzhe Jiang<div>MTS at BigSwitch</div>
</div></div>