Comment 6 for bug 1587486

Reply to comment #3:
As far as I understand, today networking-sfc alongside its OVS driver use MPLS for temporarily tagging traffic to particular chains and ppgs. Before forwarding traffic to any VM, the MPLS tag is removed. When traffic comes back, classifier re-evaluates its classification and inserts the correct tag again. So, I see the value of having the MPLS service path header-like management in networking-sfc, as it makes you closer to NSH, but is effectively not doing anything at the moment since all pps/ppgs are assumed to require an SFC Proxy, which is handled in OVS itself when it strips off and re-adds the MPLS tag. But even if MPLS was kept when sending the frames to the VMs, it still doesn't support SFC Encapsulation as I describe here, where you have branching and reclassification because you can't connect port-chains together based on SFPs - and you also can't make an NFVO to that.

I think calling my RFE SFC Encapsulation is being too general especially since you already support a part of it, so I'll probably change this. Networking-sfc wants to embrace NSH, the SFC Encapsulation protocol, so that's a good start. If the VMs don't get proxied, the scenario of port-chain #4 above will almost work because traffic will be fully encapsulated (down to layer 2, unlike MPLS which is a shim between L2 and L3) and paths will be maintained when egressing from each VM - meaning that, even if the classification is the same, we can still choose different functions depending on the actual chain that the traffic belongs to (based on the SFP). But, I say "almost" because a way to match on the SFP is still required. Maybe add SPI/SI (or NSP/NSI with current terminology) to the Flow Classifier, or maybe add that as a connection constraint in port-chains themselves - which, automatically, adds the ability to connect port-chains together to form a graph of SFPs (and not a graph of RSPs [NFPs], from ETSI MANO as far as I can understand).

So, in summmary, even if branching/reclassification and graph-like SFCs are not important, port-chains still need to be able to be connected together based on SFPs to achieve proper isolation as in the example of port-chain #4 presented earlier - otherwise, SFC Encapsulation benefits are reduced to simply allowing VMs to change the traffic class without bursting out of the current chain (but if we then want to match on that new traffic class, only one other port-chain can match on it, otherwise there will be a conflict and the only way to solve it is to isolate the new chains to specific SFPs - the connecting factor).