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