Supporting SFC Encapsulation in networking-sfc
[Metadata is a very important capability of SFC Encapsulation, but let's keep it out of scope in this specific discussion]
Let's consider the following simplified use case that requires a single Service Function Chain:
TCP optimization after receiving encrypted traffic (which may actually contain UDP and not TCP):
1. traffic is received somewhere and sent to the networking components capable of forwarding and classification;
2. if the classification is IPSec encrypted traffic, let's go to SF1: an IPSec security gateway, well prepared to decrypt IPSec traffic;
3. traffic is sent from SF1, now decrypted, towards the components capable of forwarding and classification
4. if the classification is UDP, let's go to SF2: a generic function inserted just to inspect UDP traffic - or something else;
5. if the classification is TCP, let's go to SF3: a TCP optimization function, and then go to a NAT function;
6. continue forwarding and eventual classification until the end of the SFC.
Full SFC/use case illustrated: [1]
Does this work without SFC encapsulation?
It depends. It can. Since networking-sfc does not yet support SFC encapsulation, here's how the above use case could be fulfilled with networking-sfc (please assume it is possible to classify IPSec with networking-sfc+OVS, since the actual reality is irrelevant for the discussion):
1. one port-chain made up of a single port-pair-group for the IPsec function, with flow classifier IPSec;
2. one port-chain made up of a single port-pair-group for the UDP/etc function, with flow classifier UDP, and logical_source_port equal to a specific port-pair of port-chain #1;
3. one port-chain made up of a two port-pair-groups for the TCP Optimization function and NAT function respectively, with flow classifier TCP, and logical_source_port equal to a specific port-pair of port-chain #1;
At a first glance, it seems that it would work fine. And it can. Since we can match on the respective egressing Neutron ports of each port-pair of the IPSec function PPG, we can add them as an ingressing constraint/classification when selecting the second and third port-chains (which will depend on whether traffic is UDP or TCP, the actual traffic classification).
But, what is the environment around these port chains?
What if the TCP Optimization port-pair-group (or even just one of its port-pairs) is used in another port-chain that shares the same flow classifier (TCP)? Let's call this new port-chain: port-chain #4.
If the next port-pair-group of port-chain #4, after the TCP optimizer, is not the NAT function, then traffic that flows through either port-chain #3 or #4 might get mixed and go to the wrong function.
As such, this is a possible scenario that would justify the use of SFC Encapsulation. Also, the fact that only 1 port-pair should be provided for the IPSec function is another drawback.
Does the previous scenario work by simply supporting NSH in networking-sfc?
Networking-sfc intends to support NSH and consequently SFC Encapsulation, so it would be expected that the scenario above would work fine in the future.
The issue explained previously will not occur because traffic is supposed to be encapsulated end-to-end, and will always be associated to specific Service Function Paths (SFPs = port-chains). So, traffic between the port chains #3 and #4 wouldn't really get mixed up.
But what happens when the TCP optimization function is (again) part of other chains but, in those chains, it is receiving traffic (of the same class as in port-chain #3, TCP) from another function where this latter one has multiple different sources of traffic for different port-chains.
Please see the following figure for hopefully a better illustration of the issue (SFs don't match SFs in above use case): [2]. Updated version: [4].
This is a difficult example but illustrates the need to scope service function paths to service function chains, by connecting the port-chains through SFP identifiers rather than port-pairs, or by having an additional resource which would be the service function chain (to scope the SFPs). With or without an additional resource to represent the graph, having multiple port-chains/SFPs connected through explicit SFP identifiers in the end still yields a graphs. Consequently, graphs always need to be somehow defined at Neutron level, rather than only orchestration level. Paths need to be scoped to service function chains (which are graphs) or need to be explicitly connected through SFP identifiers, or the API doesn't support SFC encapsulation.
This description is also available on the etherpad [3].
[1] http://i.imgur.com/rxzNNUZ.png
[2] http://i.imgur.com/iFqbi49.png
[3] https://etherpad.openstack.org/p/networking-sfc-and-sfc-encapsulation
[4] http://i.imgur.com/nzgatKB.png
"At a first glance, it seems that it would work fine. And it can. At least if the IPSec function has only a single port-pair, so that we can match on the respective Neutron port as the entry point for the second and third port-chains. This is a problem, but let's suppose it's okay to have a single port-pair for the IPSec function and just ignore the problem for now."
This statement is not true. Port chains 2 and 3 can be set up, each having a number of flow-classifiers that have logical source ports that are the egress ports of the IPSec SFs. If the IPsec SF port-pair-group has three IPsec SFs (SF1, SF2, SF3) then PC2 and PC3 are configured as follows.
PC2 has flow-classifiers:
FC1=SF1 egress port & UDP
FC2=SF2 egress port & UDP
FC3=SF3 egress port & UDP
PC3 has flow-classifiers:
FC4=SF1 egress port & TCP
FC5=SF2 egress port & TCP
FC6=SF3 egress port & TCP