<html><body><p><tt>John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/18/2016 03:55:14 PM:<br><br>> From: John McDowall <jmcdowall@paloaltonetworks.com></tt><br><tt>> To: Ryan Moats/Omaha/IBM@IBMUS</tt><br><tt>> Cc: "discuss@openvswitch.org" <discuss@openvswitch.org>, "OpenStack <br>> Development Mailing List" <openstack-dev@lists.openstack.org></tt><br><tt>> Date: 05/18/2016 03:55 PM</tt><br><tt>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br><tt>> <br>> Ryan,</tt><br><tt>> <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.</tt><br><tt>> <br>> <a href="https://github.com/doonhammer/networking-sfc">https://github.com/doonhammer/networking-sfc</a> </tt><br><tt>> <a href="https://github.com/doonhammer/networking-ovn">https://github.com/doonhammer/networking-ovn</a></tt><br><tt>> <a href="https://github.com/doonhammer/ovs">https://github.com/doonhammer/ovs</a> </tt><br><tt>> <br>> The next tasks I see are:</tt><br><tt>> <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.</tt><br><tt>> 2. Align the interface between networking-ovn and ovs/ovn to match <br>> the nested dictionary in 1.</tt><br><tt>> 3. Modify the ovn-nb schema and ovn-northd.c to march the port-chain model.</tt><br><tt>> 4. Add ability to support chain of port-pairs</tt><br><tt>> 5. Think about flow-classifiers and how best to map them, today I <br>> just map the logical-port and ignore everything else.</tt><br><tt>> <br>> Any other suggestions/feedback?</tt><br><tt>> <br>> Regards</tt><br><tt>> <br>> John</tt><br><br><tt>John-</tt><br><br><tt>(Sorry for sending this twice, but I forgot that text/html is not liked</tt><br><tt>by the mailing lists ...)</tt><br><tt> </tt><br><tt>My apologies for not answering this sooner - I was giving a two day</tt><br><tt>training on Tues/Wed last week and came back to my son graduating</tt><br><tt>from HS the next day, so things have been a bit of a whirlwind here.</tt><br><tt> </tt><br><tt>Looking at the github repos, I like the idea of passing a dictionary</tt><br><tt>from networking-sfc to networking-ovn. The flow classifiers should</tt><br><tt>be relatively straightforward to map to ovs match rules (famous last</tt><br><tt>words)...</tt><br><tt> </tt><br><tt>I've probably missed an orbit here, but in the ovn-northd implementation,</tt><br><tt>I was expecting to find service chains in the egress and router pipelines</tt><br><tt>in addition to the ingress pipeline (see below for why I think a service</tt><br><tt>chain stage in the egress pipeline makes sense ...)</tt><br><tt> </tt><br><tt>Also, in the ovn-northd implementation, I'm a little disturbed to see the</tt><br><tt>ingress side of the service chain sending packets to output ports - I</tt><br><tt>think that a more scalable (and more "ovs-like" approach) would be to</tt><br><tt>match the egress side of a port pair in the chaining stage of the</tt><br><tt>ingress pipeline, with an action that set the input port register.</tt><br><tt>Then the egress pipeline would have a chaining stage where the output</tt><br><tt>port register would be set based on the ingress port of the next port</tt><br><tt>pair in the chain and the packet being punted to the proper output port</tt><br><tt>in the last table. That should automagically build your function chain</tt><br><tt>and provide the basis for bucketizing multiple ingress ports for the</tt><br><tt>next port group to support hash based load balancing.</tt><br><tt> </tt><br><tt>Does that make sense?</tt><br><tt> </tt><br><tt>Ryan</tt><BR>
</body></html>