[openstack-dev] [OVN] [networking-ovn] [networking-sfc] SFC and OVN

Ryan Moats rmoats at us.ibm.com
Wed May 25 14:27:31 UTC 2016


John McDowall <jmcdowall at paloaltonetworks.com> wrote on 05/24/2016 06:33:05
PM:

> From: John McDowall <jmcdowall at paloaltonetworks.com>
> To: Ryan Moats/Omaha/IBM at IBMUS
> Cc: "discuss at openvswitch.org" <discuss at openvswitch.org>, "OpenStack
> Development Mailing List" <openstack-dev at lists.openstack.org>
> Date: 05/24/2016 06:33 PM
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> Ryan,
>
> Thanks for getting back to me and pointing me in a more OVS like
> direction. What you say makes sense, let me hack something together.
> I have been a little distracted getting some use cases together. The
> other area is how to better map the flow-classifier I have been
> thinking about it a little, but I will leave it till after we get
> the chains done.
>
> Your load-balancing comment was very interesting – I saw some
> patches for load-balancing a few months ago but nothing since. It
> would be great if we could align with load-balancing as that would
> make a really powerful solution.
>
> Regards
>
> John

John-

For the load balancing, I believe that you'll want to look at
openvswitch's select group, as that should let you set up multiple
buckets for each egress port in the port pairs that make up a port
group.

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.

Ryan

>
> From: Ryan Moats <rmoats at us.ibm.com>
> Date: Monday, May 23, 2016 at 9:06 PM
> To: John McDowall <jmcdowall at paloaltonetworks.com>
> Cc: "discuss at openvswitch.org" <discuss at openvswitch.org>, OpenStack
> Development Mailing List <openstack-dev at lists.openstack.org>
> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
>
> John McDowall <jmcdowall at paloaltonetworks.com> wrote on 05/18/2016
> 03:55:14 PM:
>
> > From: John McDowall <jmcdowall at paloaltonetworks.com>
> > To: Ryan Moats/Omaha/IBM at IBMUS
> > Cc: "discuss at openvswitch.org" <discuss at openvswitch.org>, "OpenStack
> > Development Mailing List" <openstack-dev at lists.openstack.org>
> > Date: 05/18/2016 03:55 PM
> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN
> >
> > Ryan,
> >
> > OK all three repos and now aligned with their masters. I have done
> > some simple level system tests and I can steer traffic to a single
> > VNF.  Note: some additional changes to networking-sfc to catch-up
> > with their changes.
> >
> > https://github.com/doonhammer/networking-sfc
> > https://github.com/doonhammer/networking-ovn
> > https://github.com/doonhammer/ovs
> >
> > The next tasks I see are:
> >
> > 1. Decouple networking-sfc and networking-ovn. I am thinking that I
> > will pass a nested port-chain dictionary holding port-pairs/port-
> > pair-groups/flow-classifiers from networking-sfc to networking-ovn.
> > 2. Align the interface between networking-ovn and ovs/ovn to match
> > the nested dictionary in 1.
> > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain
model.
> > 4. Add ability to support chain of port-pairs
> > 5. Think about flow-classifiers and how best to map them, today I
> > just map the logical-port and ignore everything else.
> >
> > Any other suggestions/feedback?
> >
> > Regards
> >
> > John
>
> John-
>
> (Sorry for sending this twice, but I forgot that text/html is not liked
> by the mailing lists ...)
>
> My apologies for not answering this sooner - I was giving a two day
> training on Tues/Wed last week and came back to my son graduating
> from HS the next day, so things have been a bit of a whirlwind here.
>
> Looking at the github repos, I like the idea of passing a dictionary
> from networking-sfc to networking-ovn. The flow classifiers should
> be relatively straightforward to map to ovs match rules (famous last
> words)...
>
> I've probably missed an orbit here, but in the ovn-northd implementation,
> I was expecting to find service chains in the egress and router pipelines
> in addition to the ingress pipeline (see below for why I think a service
> chain stage in the egress pipeline makes sense ...)
>
> Also, in the ovn-northd implementation, I'm a little disturbed to see the
> ingress side of the service chain sending packets to output ports - I
> think that a more scalable (and more "ovs-like" approach) would be to
> match the egress side of a port pair in the chaining stage of the
> ingress pipeline, with an action that  set the input port register.
> Then the egress pipeline would have a chaining stage where the output
> port register would be set based on the ingress port of the next port
> pair in the chain and the packet being punted to the proper output port
> in the last table.  That should automagically build your function chain
> and provide the basis for bucketizing multiple ingress ports for the
> next port group to support hash based load balancing.
>
> Does that make sense?
>
> Ryan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160525/9590539e/attachment.html>


More information about the OpenStack-dev mailing list