Icehouse Design Summit

We have three "advanced" services in Neutron today, LBaaS, FWaaS, and VPN. However, there is no API available to the user to express as to which traffic to subject these services to. For instance, a bump-in-the-wire firewall, or a tap service, or a L2 VPN would all require a subnet context. When provided, this context can be used by the provider to appropriately configure the data path and is commonly referred to as service insertion.

Moreover, with more than one service, it becomes relevant to explore the model of how multiple services can be sequenced in a chain. An example, in the context of today’s reference implementations, is the insertion and chaining of firewall and VPN services. Each of these reference implementations rely on the use of IPTable chains to program the relevant filters and policies to achieve their respective purposes. However, in the absence of a chaining abstraction to express the sequence of these services, these implementations act independently and the resulting order of operations is incidental and cannot be controlled.

In this session we will discuss how the above two issues can be solved by enhancing existing abstractions and augmenting with new abstractions in Neutron. The objective will be to support both modes of instantiating services - independently, and as a part of a chain - with support for the former in a non-disruptive fashion (since this is the default mode today).

There was discussion on this topic during the last summit. The proposed session will advance this discussion based on the feedback gained during the past six months (and build on what was added to Neutron in the H release). We will focus on transitioning to the pragmatics of what can be implemented and achieved in the Icehouse timeframe.

Etherpad: https://etherpad.openstack.org/icehouse-neutron-service-insertion-chaining

(Session proposed by Sumit Naiksatam)