Open Stack

John McDowall <jmcdowall at paloaltonetworks.com> wrote on 05/31/2016 03:19:54
PM:

> From: John McDowall <jmcdowall at paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: Ben Pfaff <blp at ovn.org>, "discuss at openvswitch.org"
> <discuss at openvswitch.org>, Justin Pettit <jpettit at ovn.org>,
> "OpenStack Development Mailing List" <openstack-
> dev at lists.openstack.org>, Russell Bryant <russell at ovn.org>
> Date: 05/31/2016 03:20 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Hopefully – just wanted to make sure it was there.
>
> Regards
>
> John

I think having that as one of the tests to make sure is a good idea...

Ryan

>
> From: Ryan Moats <rmoats at us.ibm.com>
> Date: Tuesday, May 31, 2016 at 10:02 AM
> To: John McDowall <jmcdowall at paloaltonetworks.com>
> Cc: Ben Pfaff <blp at ovn.org>, "discuss at openvswitch.org" <
> discuss at openvswitch.org>, Justin Pettit <jpettit at ovn.org>, OpenStack
> Development Mailing List <openstack-dev at lists.openstack.org>, Russell
Bryant <
> russell at ovn.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdowall at paloaltonetworks.com> wrote on 05/26/2016
> 10:59:48 AM:
>
> > From: John McDowall <jmcdowall at paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM at IBMUS, Ben Pfaff <blp at ovn.org>
> > Cc: "discuss at openvswitch.org" <discuss at openvswitch.org>, Justin
> > Pettit <jpettit at ovn.org>, OpenStack Development Mailing List
> > <openstack-dev at lists.openstack.org>, Russell Bryant <russell at 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 <rmoats at us.ibm.com>
> > Date: Wednesday, May 25, 2016 at 9:29 PM
> > To: Ben Pfaff <blp at ovn.org>
> > Cc: "discuss at openvswitch.org" <discuss at openvswitch.org>, John McDowall
<
> > jmcdowall at paloaltonetworks.com>, Justin Pettit <jpettit at ovn.org>,
> > OpenStack Development Mailing List <openstack-dev at lists.openstack.org
> > >, Russell Bryant <russell at ovn.org>
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ben Pfaff <blp at ovn.org> wrote on 05/25/2016 07:44:43 PM:
> >
> > > From: Ben Pfaff <blp at ovn.org>
> > > To: Ryan Moats/Omaha/IBM at IBMUS
> > > Cc: John McDowall <jmcdowall at paloaltonetworks.com>,
> > > "discuss at openvswitch.org" <discuss at openvswitch.org>, OpenStack
> > > Development Mailing List <openstack-dev at lists.openstack.org>, Justin
> > > Pettit <jpettit at ovn.org>, Russell Bryant <russell at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160531/dab373e2/attachment-0001.html>