Inline comments. On 15 Mar 2014, at 15:06, Kanzhe Jiang <[email protected]> wrote:
> On Fri, Mar 14, 2014 at 3:18 PM, Mohammad Banikazemi <[email protected]> wrote: > 1- This fits ok with the policy model we had developed earlier where the > policy would get defined between a source and a destination policy endpoint > group. The chain could be instantiated at the time the policy gets defined. > (More questions on the instantiation below marked as 1.a and 1.b.) How would > that work in a contract based model for policy? At the time a contract is > defined, it's producers and consumers are not defined yet. Would we postpone > the instantiation of the service chain to the time a contract gets a producer > and at least a consumer? > > In a contract based model, we can add a state attribute to the service chain. > Once a contract is defined, a corresponding chain could be defined without > insertion contexts. The chain state is "pending". I assume the producer and > consumers can be used to derive the source and destination insertion contexts > for the chain. Once a contract gets producer and a consumer, the chain can > then be instantiated. When new consumers are added, the chain would verify if > the new context can be supported before updating the existing contexts. If > all producer and consumers are removed from a contract, the chain provider > deletes all service instances in the chain. Exactly. I was about to suggest the same. > 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. Does any of this even make any sense? :-) On a side note, it may be worth watching one of the two OpenContrail’s videos demonstrating their approach on service chain: - http://opencontrail.org/videogallery/elastic-ssl-vpn-service-over-contrail-for-secure-mobile-connectivity/ - http://opencontrail.org/videogallery/dynamic-and-elastic-anti-ddos-service-through-contrail-and-ddos-secure/ Thanks, Carlos Goncalves
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
