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