[openstack-dev] [Neutron][NFV][Advanced Services][group-policy] Traffic Steering and chaining discussion

Carlos Gonçalves mail at cgoncalves.pt
Fri Jun 27 18:06:48 UTC 2014

Hi all,

The present email regards the Traffic Steering (TS) blueprint [1][2] being proposed. It should be of relevance to the Group-based Policy (GBP) work [3], to the Service Chaining (SC) blueprint [4], to the NFV and Neutron teams in general as such work could be leveraged to help implement networking services.

Current blueprint [1] patchset suggests TS as an enabler for SC [4]. While such could be made possible, there are some aspects TS does not contemplate and are of great importance for SC, with one being creating a virtual network function (VNF) overlay so that traffic transverses VNF defined by a specific VNF Forwarding Graph (VNF-FG) and does not get mixed with other VNF-FG overlays. Other aspect brought to discussion was traffic classification resource and possibly overlapping with the Group-based Policy classifier resource. These are the two main items being discussed right now, right? Let me further detail and present my view of the two separately.

Service Chaining:
As mentioned above, TS might not completely cover SC minimum requirements to be used as a mechanism driver. Traffic is basically steered as a pair of ports. For instance, in a SC X -> Y -> Z (X,Y and Z represent VNFs), two port steerings should be created: X -> Y and Y -> Z, and associated to one or more traffic classifiers. Now if VNF Y is shared by a second chain (W -> Y -> Q) and classifier is the same, there is a conflict to where the traffic should flow to (VNF Z or VNF Q). This is why an overlay is needed (e.g. one possibility to accomplish this could be by marking/tagging packets). Thus, TS fails on meeting this scenario because it does not address network overlays, and it shouldn’t IMO. It should stick to the ability of steering traffic from point A to point B (although from a service abstraction viewpoint we allow the specification of multiple points – ultimately a graph – for flexibility purposes).

Moreover, and providing my insights on how SC could be realized: with recent efforts on the SDN controllers for supporting Service Function Chaining (SFC) such as ODL [5] and OpenContrail [6], it is of my opinion that SC on OpenStack could be better handled by adding support to those mechanisms as they internally create the overlays, or other ways they see fit, needed to realize proper VNF-FGs. Of course OVS support should also be implemented (potentially useful references [7] [8] [9]). Note that we are not excluding the ability to use TS as the backend for SC, we are just highlighting that it is not the perfect way to do it. While there is no perfect way, TS can naturally do the job.

So, SC creates a VNF-FG and has an entry-point (first VNF in chain) and an exit-point (last VNF in chain). As the blueprint is specified as of now, I don’t see how one is capable of forwarding traffic to a given SC. The GBP is a good example of dependable service that relies on SC as it has a ‘redirect’ action to a SC UUID (also supports to a Neutron service UUID). Specifically its mapping driver should somehow steer traffic to the SC, but I’m now aware of how the GBP folks plan on doing that. My understanding is that they should potentially back on the TS work to do so, assuming a SC instance entry-point could be manifested as a Neutron port (which would be the entry point of the SC overlay, and not necessarily the port of a VNF). I’d like to hear more from the GBP on their plans on the ‘redirect’ action and suggestion to use TS there.

Note that TS is not restricted to the context of SC and/or GBP. It can be consumed by any other service in OpenStack or as standalone presented to admins via API.

Classifier Resource:
Cathy has recently raised an interesting point on traffic classification. Both TS and GBP blueprints propose Classifier resources that are almost identical. In fact, the TS Classifier resource was initially based on GBP’s. Long story short, both works should continue supporting such resource but converge to a single one. From python-neutronclient point-of-view:

	$ neutron policy-classifier-*
	$ neutron steering-classifier-*

Would become just:

	$ neutron classifier-*

Future services needing traffic classification could leverage this very same resource.

All: what’s your view on these two subjects? I’m open to suggestions.

Carlos Goncalves

[1] https://review.openstack.org/#/c/92477/
[2] https://blueprints.launchpad.net/neutron/+spec/traffic-steering-abstraction
[3] https://blueprints.launchpad.net/neutron/+spec/group-based-policy-abstraction
[4] https://review.openstack.org/#/c/93524
[5] https://wiki.opendaylight.org/view/Project_Proposals:Service_function_chaining
[6] http://opencontrail.org/opencontrail-architecture-documentation/#section2_3
[7] https://lists.opendaylight.org/pipermail/sfc-dev/2014-June/000115.html
[8] https://lists.opendaylight.org/pipermail/sfc-dev/attachments/20140624/98d174a8/attachment-0001.pdf
[9] https://docs.google.com/file/d/0BzS_qWNqsnQbR01Hay14Wm01dlk

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140627/6747715f/attachment.html>

More information about the OpenStack-dev mailing list