Open Stack

Ryan,

Hopefully – just wanted to make sure it was there.

Regards

John

From: Ryan Moats <rmoats at us.ibm.com<mailto:rmoats at us.ibm.com>>
Date: Tuesday, May 31, 2016 at 10:02 AM
To: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
Cc: Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>>, "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>, Justin Pettit <jpettit at ovn.org<mailto:jpettit at ovn.org>>, OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, Russell Bryant <russell at ovn.org<mailto:russell at ovn.org>>
Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN


John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>> wrote on 05/26/2016 10:59:48 AM:

> From: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>
> To: Ryan Moats/Omaha/IBM at IBMUS, Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>>
> Cc: "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>, Justin
> Pettit <jpettit at ovn.org<mailto:jpettit at ovn.org>>, OpenStack Development Mailing List
> <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, Russell Bryant <russell at ovn.org<mailto: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<mailto:rmoats at us.ibm.com>>
> Date: Wednesday, May 25, 2016 at 9:29 PM
> To: Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>>
> Cc: "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>, John McDowall <
> jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>, Justin Pettit <jpettit at ovn.org<mailto:jpettit at ovn.org>>,
> OpenStack Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>
> >, Russell Bryant <russell at ovn.org<mailto:russell at ovn.org>>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>> wrote on 05/25/2016 07:44:43 PM:
>
> > From: Ben Pfaff <blp at ovn.org<mailto:blp at ovn.org>>
> > To: Ryan Moats/Omaha/IBM at IBMUS
> > Cc: John McDowall <jmcdowall at paloaltonetworks.com<mailto:jmcdowall at paloaltonetworks.com>>,
> > "discuss at openvswitch.org<mailto:discuss at openvswitch.org>" <discuss at openvswitch.org<mailto:discuss at openvswitch.org>>, OpenStack
> > Development Mailing List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>, Justin
> > Pettit <jpettit at ovn.org<mailto:jpettit at ovn.org>>, Russell Bryant <russell at ovn.org<mailto: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/46d0aa12/attachment.html>