Open Stack

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/20160525/ce0118e8/attachment.html>