<html><body><p><tt>John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/26/2016 11:08:43 AM:<br><br>> From: John McDowall <jmcdowall@paloaltonetworks.com></tt><br><tt>> To: Ryan Moats/Omaha/IBM@IBMUS</tt><br><tt>> Cc: Ben Pfaff <blp@ovn.org>, "discuss@openvswitch.org" <br>> <discuss@openvswitch.org>, Justin Pettit <jpettit@ovn.org>, <br>> "OpenStack Development Mailing List" <openstack-<br>> dev@lists.openstack.org>, Russell Bryant <russell@ovn.org></tt><br><tt>> Date: 05/26/2016 11:09 AM</tt><br><tt>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br><tt>> <br>> Ryan,</tt><br><tt>> <br>> My (incomplete) throughts about the flow-classifier are:</tt><br><tt>> <br>> 1) ACL’s are more about denying access, while the flow classifier <br>> is more about steering selected traffic to a path, so we would need <br>> to deny-all except allowed flows.</tt><br><tt>> 2) The networking-sfc team has done a nice job with the drivers so <br>> ovn has its own flow-classifier driver which allows us to align the <br>> flow-classifier with the matches supported in ovs/ovn, which could <br>> be an advantage.</tt><br><br><tt>The ACL table has a very simple flow-classifier structure and I'd</tt><br><tt>like to see if that can be re-used for the purpose of the SFC classifier</tt><br><tt>(read that I feel the Logical_Flow_Classifier table is too complex).</tt><br><tt>My initial thoughts were to look at extending the action column and</tt><br><tt>using the external-ids field to differentiate between legacy ACLs and</tt><br><tt>those that are used to intercept traffic and route it to an SFC.</tt><br><br><tt>> <br>> What were your thoughts on the schema it adds a lot of tables and a <br>> lot of commands – cannot think of anyway around it</tt><br><br><tt>In this case, I think that the other tables are reasonable and I'm </tt><br><tt>uncomfortable trying to stretch the existing tables to cover that</tt><br><tt>information...</tt><br><br><tt>Ryan</tt><br><br><tt>> <br>> Regards</tt><br><tt>> <br>> John</tt><br><tt>> <br>> From: Ryan Moats <rmoats@us.ibm.com><br>> Date: Wednesday, May 25, 2016 at 9:12 PM<br>> To: John McDowall <jmcdowall@paloaltonetworks.com><br>> Cc: Ben Pfaff <blp@ovn.org>, "discuss@openvswitch.org" <<br>> discuss@openvswitch.org>, Justin Pettit <jpettit@ovn.org>, OpenStack<br>> Development Mailing List <openstack-dev@lists.openstack.org>, Russell Bryant <<br>> russell@ovn.org><br>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br><tt>> <br>> John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/25/2016 <br>> 07:27:46 PM:<br>> <br>> > From: John McDowall <jmcdowall@paloaltonetworks.com><br>> > To: Ryan Moats/Omaha/IBM@IBMUS<br>> > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, "OpenStack <br>> > Development Mailing List" <openstack-dev@lists.openstack.org>, Ben <br>> > Pfaff <blp@ovn.org>, Justin Pettit <jpettit@ovn.org>, Russell Bryant<br>> > <russell@ovn.org><br>> > Date: 05/25/2016 07:28 PM<br>> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > <br>> > Ryan,<br>> > <br>> > Ok – I will let the experts weigh in on load balancing.<br>> > <br>> > In the meantime I have attached a couple of files to show where I am<br>> > going. The first is sfc_dict.py and is a representation of the dict <br>> > I am passing from SFC to OVN. This will then translate to the <br>> > attached ovn-nb schema file.<br>> > <br>> > One of my concerns is that SFC almost doubles the size of the ovn-nb<br>> > schema but I could not think of any other way of doing it.<br>> > <br>> > Thoughts?<br>> > <br>> > John<br>> <br>> The dictionary looks fine for a starting point, and the more I look<br>> at the classifier, the more I wonder if we can't do something with<br>> the current ACL table to avoid duplication in the NB database<br>> definition...<br>> <br>> Ryan<br>> <br>> > From: Ryan Moats <rmoats@us.ibm.com><br>> > Date: Wednesday, May 25, 2016 at 7:27 AM<br>> > To: John McDowall <jmcdowall@paloaltonetworks.com><br>> > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, OpenStack <br>> > Development Mailing List <openstack-dev@lists.openstack.org>, Ben Pfaff <<br>> > blp@ovn.org>, Justin Pettit <jpettit@ovn.org>, Russell Bryant <<br>> russell@ovn.org<br>> > ><br>> > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > <br>> > John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/24/2016 <br>> > 06:33:05 PM:<br>> > <br>> > > From: John McDowall <jmcdowall@paloaltonetworks.com><br>> > > To: Ryan Moats/Omaha/IBM@IBMUS<br>> > > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, "OpenStack <br>> > > Development Mailing List" <openstack-dev@lists.openstack.org><br>> > > Date: 05/24/2016 06:33 PM<br>> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > > <br>> > > Ryan,<br>> > > <br>> > > Thanks for getting back to me and pointing me in a more OVS like <br>> > > direction. What you say makes sense, let me hack something together.<br>> > > I have been a little distracted getting some use cases together. The<br>> > > other area is how to better map the flow-classifier I have been <br>> > > thinking about it a little, but I will leave it till after we get <br>> > > the chains done.<br>> > > <br>> > > Your load-balancing comment was very interesting – I saw some <br>> > > patches for load-balancing a few months ago but nothing since. It <br>> > > would be great if we could align with load-balancing as that would <br>> > > make a really powerful solution.<br>> > > <br>> > > Regards<br>> > > <br>> > > John<br>> > <br>> > John-<br>> > <br>> > For the load balancing, I believe that you'll want to look at<br>> > openvswitch's select group, as that should let you set up multiple<br>> > buckets for each egress port in the port pairs that make up a port<br>> > group.<br>> > <br>> > As I understand it, Table 0 identifies the logical port and logical<br>> > flow. I'm worried that this means we'll end up with separate bucket<br>> > rules for each ingress port of the port pairs that make up a port<br>> > group, leading to a cardinality product in the number of rules.<br>> > I'm trying to think of a way where Table 0 could identify the packet<br>> > as being part of a particular port group, and then I'd only need one<br>> > set of bucket rules to figure out the egress side. However, the<br>> > amount of free metadata space is limited and so before we go down<br>> > this path, I'm going to pull Justin, Ben and Russell in to see if<br>> > they buy into this idea or if they can think of an alternative.<br>> > <br>> > Ryan<br>> > <br>> > > <br>> > > From: Ryan Moats <rmoats@us.ibm.com><br>> > > Date: Monday, May 23, 2016 at 9:06 PM<br>> > > To: John McDowall <jmcdowall@paloaltonetworks.com><br>> > > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, OpenStack <br>> > > Development Mailing List <openstack-dev@lists.openstack.org><br>> > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > > <br>> > > John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/18/2016 <br>> > > 03:55:14 PM:<br>> > > <br>> > > > From: John McDowall <jmcdowall@paloaltonetworks.com><br>> > > > To: Ryan Moats/Omaha/IBM@IBMUS<br>> > > > Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, "OpenStack <br>> > > > Development Mailing List" <openstack-dev@lists.openstack.org><br>> > > > Date: 05/18/2016 03:55 PM<br>> > > > Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>> > > > <br>> > > > Ryan,<br>> > > > <br>> > > > OK all three repos and now aligned with their masters. I have done <br>> > > > some simple level system tests and I can steer traffic to a single <br>> > > > VNF. Note: some additional changes to networking-sfc to catch-up <br>> > > > with their changes.<br>> > > > <br>> > > > <a href="https://github.com/doonhammer/networking-sfc">https://github.com/doonhammer/networking-sfc</a> <br>> > > > <a href="https://github.com/doonhammer/networking-ovn">https://github.com/doonhammer/networking-ovn</a><br>> > > > <a href="https://github.com/doonhammer/ovs">https://github.com/doonhammer/ovs</a> <br>> > > > <br>> > > > The next tasks I see are:<br>> > > > <br>> > > > 1. Decouple networking-sfc and networking-ovn. I am thinking that I <br>> > > > will pass a nested port-chain dictionary holding port-pairs/port-<br>> > > > pair-groups/flow-classifiers from networking-sfc to networking-ovn.<br>> > > > 2. Align the interface between networking-ovn and ovs/ovn to match <br>> > > > the nested dictionary in 1.<br>> > > > 3. Modify the ovn-nb schema and ovn-northd.c to march the port-<br>> > chain model.<br>> > > > 4. Add ability to support chain of port-pairs<br>> > > > 5. Think about flow-classifiers and how best to map them, today I <br>> > > > just map the logical-port and ignore everything else.<br>> > > > <br>> > > > Any other suggestions/feedback?<br>> > > > <br>> > > > Regards<br>> > > > <br>> > > > John<br>> > > <br>> > > John-<br>> > > <br>> > > (Sorry for sending this twice, but I forgot that text/html is not liked<br>> > > by the mailing lists ...)<br>> > > <br>> > > My apologies for not answering this sooner - I was giving a two day<br>> > > training on Tues/Wed last week and came back to my son graduating<br>> > > from HS the next day, so things have been a bit of a whirlwind here.<br>> > > <br>> > > Looking at the github repos, I like the idea of passing a dictionary<br>> > > from networking-sfc to networking-ovn. The flow classifiers should<br>> > > be relatively straightforward to map to ovs match rules (famous last<br>> > > words)...<br>> > > <br>> > > I've probably missed an orbit here, but in the ovn-northd implementation,<br>> > > I was expecting to find service chains in the egress and router pipelines<br>> > > in addition to the ingress pipeline (see below for why I think a service<br>> > > chain stage in the egress pipeline makes sense ...)<br>> > > <br>> > > Also, in the ovn-northd implementation, I'm a little disturbed to see the<br>> > > ingress side of the service chain sending packets to output ports - I<br>> > > think that a more scalable (and more "ovs-like" approach) would be to<br>> > > match the egress side of a port pair in the chaining stage of the<br>> > > ingress pipeline, with an action that set the input port register.<br>> > > Then the egress pipeline would have a chaining stage where the output<br>> > > port register would be set based on the ingress port of the next port<br>> > > pair in the chain and the packet being punted to the proper output port<br>> > > in the last table. That should automagically build your function chain<br>> > > and provide the basis for bucketizing multiple ingress ports for the<br>> > > next port group to support hash based load balancing.<br>> > > <br>> > > Does that make sense?<br>> > > <br>> > > Ryan[attachment "ovn-nb.ovsschema.sfc" deleted by Ryan Moats/<br>> > Omaha/IBM] [attachment "sfc_dict.py" deleted by Ryan Moats/Omaha/IBM] </tt><BR>
</body></html>