<html><body><p>In-line below<br><br><tt>"discuss" <discuss-bounces@openvswitch.org> wrote on 06/15/2016 05:51:20 PM:<br><br>> From: John McDowall <jmcdowall@paloaltonetworks.com></tt><br><tt>> To: Na Zhu <nazhu@cn.ibm.com></tt><br><tt>> Cc: Srilatha Tangirala/San Francisco/IBM@IBMUS, "OpenStack <br>> Development Mailing List \(not for usage questions\)" <openstack-<br>> dev@lists.openstack.org>, discuss <discuss@openvswitch.org></tt><br><tt>> Date: 06/15/2016 05:51 PM</tt><br><tt>> Subject: Re: [ovs-discuss] [openstack-dev] [OVN] [networking-ovn] <br>> [networking-sfc] SFC andOVN</tt><br><tt>> Sent by: "discuss" <discuss-bounces@openvswitch.org></tt><br><tt>> <br>> Juno,</tt><br><tt>> <br>> Apologies – I see your issue now, also I have got nothing done today<br>> – got sucked into an all day meeting. I was thinking very much from <br>> a  ovs/ovn perspective and also my first prototype was very simple. </tt><br><tt>> <br>> So while in networking=sfc/ovn the port-cahin does not have a switch<br>> I think port-chain needs a lswitch context as that is where the <br>> port-chain table is created. Let me try and lay this out. I am not <br>> sure if I am getting this right but it is a starting point for <br>> discussion and comment by the community.</tt><br><tt>> <br>> The first thing is that there could be three different types of <br>> VNF’s, L3, L2, and Bump in the Wire (BITW). I am not sure if it <br>> would be possible to mix and match these different types in a series<br>> of port-pair-groups. Also as a first phase I have been trying to <br>> remove the need for the VNF to participate in the service chain (or <br>> be aware of it). In addition I also wanted to remove the need for <br>> any “proxy” as documented in the NSH model, by moving a lot of the <br>> functionality to the ovn-northd.</tt><br><tt>> <br>> Mode 1: BITW</tt><br><tt>> Port-Pairs: The logical ports need to be on the same logical switch</tt><br><tt>> Port-pair-groups: They are made up of sets of port-pairs, until we <br>> see the load-balancing proposal for ovs/ovn not sure if port-pairs <br>> can be on different logical switches or not. This translates to a <br>> set of rules in the port-chain table that chains output ports of one<br>> VNF to the input port of the next VNF, until the last VNF when the <br>> traffic is forwarded to the final destination of the packet. If the <br>> port-chain is bi-directional then the rule set has to be implemented<br>> in reverse (many VNF’s Firewalls, Load Balancers etc need to see <br>> both legs of the traffic).</tt><br><tt>> Flow-classifier: Is a set of rules that are set as an ACL rule with <br>> first logical port of the first pair in the first port-pair-group. <br>> Likewise if the port-chain is bi-directional then the rules have to <br>> be symmetric to steer the traffic in both directions.</tt><br><tt>> Port-chain: defined on the same logical switch as the first logical-<br>> source-port of the flow-classifier, as this is where the port-chain <br>> table is created and the rules for traffic steering are inserted.</tt><br><tt>> Mode 2: L2</tt><br><tt>> <br>> I think this would be similar to the BITH case but instead of <br>> steering by logical ports the steering would be done by VLAN tags. <br>> This would also mean that the VNFs would have to be aware of the <br>> steering rules and be able to manipulate VLAN tags.</tt><br><tt>> <br>> Mode 3: L3</tt><br><tt>> <br>> This would require the VNF’s to be aware of the routing rules and <br>> set static routes/net hop rules for each step in the service chain. </tt><br><tt>> <br>> Modes 2 & 3 would require a much more sophisticated control plane to<br>> program both OVN and the VNFs.</tt><br><br><tt>[Snip to save BW]</tt><br><br><tt>I'm not so sure John.  I agree that OVN would have to know about the</tt><br><tt>VF type (BiW/L2/L3) and further that OVN would need to be told about</tt><br><tt>the appropriate L2/L3 "next port" information - either VLAN tags or</tt><br><tt>IP addresses, but once I have that, I think the actual vswitch</tt><br><tt>programming is fairly straightforward:  for L2, the vswitch is</tt><br><tt>programmed to use the VLAN tag to select the next PPG bucket and</tt><br><tt>for L3, the existing template for programming static routes can be</tt><br><tt>leveraged.</tt><br><br><tt>Ryan</tt><BR>
</body></html>