<html><body><p><tt>John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/31/2016 03:19:54 PM:<br><br>> From: John McDowall <jmcdowall@paloaltonetworks.com></tt><br><tt>> To: Ryan Moats/Omaha/IBM@IBMUS</tt><br><tt>> Cc: Ben Pfaff <blp@ovn.org>, "discuss@openvswitch.org" <br>> <discuss@openvswitch.org>, Justin Pettit <jpettit@ovn.org>, <br>> "OpenStack Development Mailing List" <openstack-<br>> dev@lists.openstack.org>, Russell Bryant <russell@ovn.org></tt><br><tt>> Date: 05/31/2016 03:20 PM</tt><br><tt>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br><tt>> <br>> Ryan,</tt><br><tt>> <br>> Hopefully – just wanted to make sure it was there.</tt><br><tt>> <br>> Regards</tt><br><tt>> <br>> John</tt><br><br><tt>I think having that as one of the tests to make sure is a good idea...</tt><br><br><tt>Ryan</tt><br><br><tt>> <br>> From: Ryan Moats <rmoats@us.ibm.com><br>> Date: Tuesday, May 31, 2016 at 10:02 AM<br>> To: John McDowall <jmcdowall@paloaltonetworks.com><br>> Cc: Ben Pfaff <blp@ovn.org>, "discuss@openvswitch.org" <<br>> discuss@openvswitch.org>, Justin Pettit <jpettit@ovn.org>, OpenStack<br>> Development Mailing List <openstack-dev@lists.openstack.org>, Russell Bryant <<br>> russell@ovn.org><br>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br><tt>> <br>> John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/26/2016 <br>> 10:59:48 AM:<br>> <br>> > From: John McDowall <jmcdowall@paloaltonetworks.com><br>> > To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff <blp@ovn.org><br>> > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, Justin <br>> > Pettit <jpettit@ovn.org>, OpenStack Development Mailing List <br>> > <openstack-dev@lists.openstack.org>, Russell Bryant <russell@ovn.org><br>> > Date: 05/26/2016 11:00 AM<br>> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > <br>> > Ryan,<br>> > <br>> > Agree with your description of the problem. The only thing I would <br>> > add is that in the case of bi-directional chains the return flows <br>> > need to go through the same VNF(Port-pair).<br>> <br>> I'm pretty sure that is caught automagically, isn't it?<br>> <br>> Ryan<br>> <br>> > <br>> > Regards<br>> > <br>> > John<br>> > <br>> > From: Ryan Moats <rmoats@us.ibm.com><br>> > Date: Wednesday, May 25, 2016 at 9:29 PM<br>> > To: Ben Pfaff <blp@ovn.org><br>> > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, John McDowall <<br>> > jmcdowall@paloaltonetworks.com>, Justin Pettit <jpettit@ovn.org>, <br>> > OpenStack Development Mailing List <openstack-dev@lists.openstack.org<br>> > >, Russell Bryant <russell@ovn.org><br>> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > <br>> > Ben Pfaff <blp@ovn.org> wrote on 05/25/2016 07:44:43 PM:<br>> > <br>> > > From: Ben Pfaff <blp@ovn.org><br>> > > To: Ryan Moats/Omaha/IBM@IBMUS<br>> > > 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><br>> > > Date: 05/25/2016 07:44 PM<br>> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > > <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>> > <br>> > Sure (and John gets to correct me where I'm wrong) - the SFC proposal<br>> > is to carry a chain as a ordered set of port groups, where each group <br>> > consists of multiple port pairs. Each port pair consists of an ingress<br>> > port and an egress port, so that traffic is load balanced between<br>> > the ingress ports of a group. Traffic from the egress port of a group <br>> > is sent to the ingress port of the next group (ingress and egress here<br>> > are from the point of view of the thing getting the traffic).<br>> > <br>> > I was suggesting to John that from the view of the switch, this would<br>> > be reversed in the openvswitch rules - the proposed CHAINING stage<br>> > in the ingress pipeline would apply the classifier for traffic entering<br>> > a chain and identify traffic coming from an egress SFC port in the<br>> > midst of a chain. The egress pipeline would identify the next ingress SFC<br>> > port that gets the traffic or the final destination for traffic exiting<br>> > the chain.<br>> > <br>> > Further, I pointed him at the select group for how traffic could be<br>> > load balanced between the different ports that are contained in a port<br>> > group, but that I was worried that I'd need a cartesian product of rules<br>> > in the egress chain stage. Having thought about this some more, I'm<br>> > realizing that I'm confused and the number of rules should not be that<br>> > bad:<br>> > <br>> > - Table 0 will identify the logical port the traffic comes from<br>> > - The CHAINING stage of the ingress pipeline can map that logical<br>> > port information to the port group the port is part of.<br>> > - The CHAINING stage of the egress pipeline would use that port<br>> > group information to select the next logical port via a select group.<br>> > <br>> > I believe this requires a total number of rules in the CHAINING stages<br>> > of the order of the number of ports in the service chain.<br>> > <br>> > The above is predicated on carrying the port group information from<br>> > the ingress pipeline to the egress pipeline in metadata, so I would<br>> > be looking to you for ideas on where this data could be carried, since<br>> > I know that we don't have infinite space for said metadata...<br>> > <br>> > Ryan<br></tt><BR>
</body></html>