Ryan, Agree with your description of the problem. The only thing I would add is that in the case of bi-directional chains the return flows need to go through the same VNF(Port-pair).
Regards John From: Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>> Date: Wednesday, May 25, 2016 at 9:29 PM To: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>> Cc: "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" <discuss@openvswitch.org<mailto:discuss@openvswitch.org>>, John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>, Justin Pettit <jpet...@ovn.org<mailto:jpet...@ovn.org>>, OpenStack Development Mailing List <openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org>>, Russell Bryant <russ...@ovn.org<mailto:russ...@ovn.org>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>> wrote on 05/25/2016 07:44:43 PM: > From: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>> > To: Ryan Moats/Omaha/IBM@IBMUS > Cc: John McDowall > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>>, > "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" > <discuss@openvswitch.org<mailto:discuss@openvswitch.org>>, OpenStack > Development Mailing List > <openstack-...@lists.openstack.org<mailto:openstack-...@lists.openstack.org>>, > Justin > Pettit <jpet...@ovn.org<mailto:jpet...@ovn.org>>, Russell Bryant > <russ...@ovn.org<mailto:russ...@ovn.org>> > Date: 05/25/2016 07:44 PM > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN > > On Wed, May 25, 2016 at 09:27:31AM -0500, Ryan Moats wrote: > > As I understand it, Table 0 identifies the logical port and logical > > flow. I'm worried that this means we'll end up with separate bucket > > rules for each ingress port of the port pairs that make up a port > > group, leading to a cardinality product in the number of rules. > > I'm trying to think of a way where Table 0 could identify the packet > > as being part of a particular port group, and then I'd only need one > > set of bucket rules to figure out the egress side. However, the > > amount of free metadata space is limited and so before we go down > > this path, I'm going to pull Justin, Ben and Russell in to see if > > they buy into this idea or if they can think of an alternative. > > I've barely been following the discussion, so a recap of the question > here would help a lot. > Sure (and John gets to correct me where I'm wrong) - the SFC proposal is to carry a chain as a ordered set of port groups, where each group consists of multiple port pairs. Each port pair consists of an ingress port and an egress port, so that traffic is load balanced between the ingress ports of a group. Traffic from the egress port of a group is sent to the ingress port of the next group (ingress and egress here are from the point of view of the thing getting the traffic). I was suggesting to John that from the view of the switch, this would be reversed in the openvswitch rules - the proposed CHAINING stage in the ingress pipeline would apply the classifier for traffic entering a chain and identify traffic coming from an egress SFC port in the midst of a chain. The egress pipeline would identify the next ingress SFC port that gets the traffic or the final destination for traffic exiting the chain. Further, I pointed him at the select group for how traffic could be load balanced between the different ports that are contained in a port group, but that I was worried that I'd need a cartesian product of rules in the egress chain stage. Having thought about this some more, I'm realizing that I'm confused and the number of rules should not be that bad: - Table 0 will identify the logical port the traffic comes from - The CHAINING stage of the ingress pipeline can map that logical port information to the port group the port is part of. - The CHAINING stage of the egress pipeline would use that port group information to select the next logical port via a select group. I believe this requires a total number of rules in the CHAINING stages of the order of the number of ports in the service chain. The above is predicated on carrying the port group information from the ingress pipeline to the egress pipeline in metadata, so I would be looking to you for ideas on where this data could be carried, since I know that we don't have infinite space for said metadata... Ryan
_______________________________________________ discuss mailing list discuss@openvswitch.org http://openvswitch.org/mailman/listinfo/discuss
