Ryan, Hopefully – just wanted to make sure it was there.
Regards John From: Ryan Moats <rmo...@us.ibm.com<mailto:rmo...@us.ibm.com>> Date: Tuesday, May 31, 2016 at 10:02 AM To: John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> Cc: Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>>, "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" <discuss@openvswitch.org<mailto:discuss@openvswitch.org>>, 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 John McDowall <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> wrote on 05/26/2016 10:59:48 AM: > From: John McDowall > <jmcdow...@paloaltonetworks.com<mailto:jmcdow...@paloaltonetworks.com>> > To: Ryan Moats/Omaha/IBM@IBMUS, Ben Pfaff <b...@ovn.org<mailto:b...@ovn.org>> > Cc: "discuss@openvswitch.org<mailto:discuss@openvswitch.org>" > <discuss@openvswitch.org<mailto:discuss@openvswitch.org>>, 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>> > Date: 05/26/2016 11:00 AM > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN > > 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). I'm pretty sure that is caught automagically, isn't it? Ryan > > 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
