[ovs-dev] SFC ACL and Flow Classifier

[Farhad Sunavala]

Hi John:
Please see inline for FS:
Message: 3
Date: Tue, 12 Jul 2016 22:32:58 +0000
From: John McDowall <jmcdowall at paloaltonetworks.com>
To: "dev at openvswitch.org" <dev at openvswitch.org>
Subject: [ovs-dev] SFC ACL and Flow Classifier
Message-ID: <D3A968E2.6225%jmcdowall at paloaltonetworks.com>
Content-Type: text/plain; charset="iso-8859-1"


Based on Ryan's suggestions, here is my proposal for implementing the SFC flowClassifier as ACLs. I wanted to get some feedback before I get into another round of changes in the code.

Currently I have implemented SFC by adding a new table (ls_in_chain) in the ova-stage of ovn-northd.c as follows:

/* Logical switch ingress stages. */ \
  PIPELINE_STAGE(SWITCH, IN,  PORT_SEC_L2,    0, "ls_in_port_sec_l2") \
  PIPELINE_STAGE(SWITCH, IN,  PORT_SEC_IP,    1, "ls_in_port_sec_ip") \
  PIPELINE_STAGE(SWITCH, IN,  PORT_SEC_ND,    2, "ls_in_port_sec_nd") \
  PIPELINE_STAGE(SWITCH, IN,  PRE_ACL,        3, "ls_in_pre_acl") \
  PIPELINE_STAGE(SWITCH, IN,  ACL,            4, "ls_in_acl") \
  PIPELINE_STAGE(SWITCH, IN,  ARP_RSP,        5, "ls_in_arp_rsp") \
  PIPELINE_STAGE(SWITCH, IN,  CHAIN,          6, "ls_in_chain") \
  PIPELINE_STAGE(SWITCH, IN,  L2_LKUP,        7, "ls_in_l2_lkup") \
In that table I insert four rules, two for the ingress direction and two for the egress direction. The pseudo code for the rules is as follows:

Ingress Direction

Rule 1: Priority 100:  if  [ dst_ip == flow classifier source ] then [send to first input port of chain]
FS: So, this rule will be applied to all compute hosts.  networking-sfc forces user to input --logical-source-port so that you can narrow down the source of the incoming traffic and apply the rule to only that host.    
Also, just matching on dst_ip is too general. Why not match on the entire classifier?What is there are 2 types of traffic going to destinationand they have to be chained differently?  E.g. TCP and UDP traffic need to be chained differently.

Rule 2: Priority 150: if [ dst_ip == flow classifier source && in_port == chain out_port ] then [send to next chain in_port]
(if out_port is last port-pair in ingress direction then send to flow classifier source port)

FS: OK.Same comment as above for matching on the entire flow classifier.

Egress Direction

Rule 3: Priority 125: if [ src_ip == flow classifier source ] then [send to first output port of chain]
FS: I think I follow what you are trying to do (reverse direction chaining) but I'm not too clear.

What if my flow-classifier is as follows:ip.src = 192.168.0.3, ip.dst = 192.168.0.4,  and service function in the chain is 192.168.0.5
A packet matching ip.dst will hit on ingress chain, set logical destination index to in_port of sf1 and then progress to egress chain.  Here is will hit the egress rule and get redirected to out_portof sf1.    Or is my understanding incorrect ?

Rule 4 Priority 150: if [src_ip == flow classifier source && in_port == chain in_port ] then [send to next chain out_port]
( if in_port is in last port-pair in egress direction then send to final destination )

FS: Same comment as above. 
Thanks,Farhad.

The design goal is to have Rule 1 and 3 be set as ACL rules, where the ACL is the flow-classifier for the SFC.

I propose to remove Rule 1 and 3 from the ls-in-chain table and add a new ACL action "sfc" so that rules like:

acl-add lsw0 to-lport 1000 'eth.type == 0x1236 && inport == app-port' sfc

Will direct the flows into the service chain.

The SFC action will resubmit the flow to the ls-in-chain table (OVS table 22 in my current implementation), including the to/from info to direct to rule 2 or 4.
This approach has the advantage of using any parameter to classify flows that is supported by OVS/OVN.

The only area that users need to be careful about is the priority setting in the ACL rule. If not set correcyl the sfc rule could be skipped but that is a normal issue with ACL rules.

Thoughts?

John