<html><body><p><tt>John McDowall <jmcdowall@paloaltonetworks.com> wrote on 05/08/2016 07:34:52 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></tt><br><tt>> Date: 05/08/2016 07:35 PM</tt><br><tt>> Subject: Re: [OVN] [networking-ovn] [networking-sfc] SFC and OVN</tt><br><tt>> <br>> Correcting ovs address</tt><br><tt>> <br>> Ryan,</tt><br><tt>> <br>> Thanks for taking a look at these - really appreciate it. I will <br>> work on the rebasing this week and get everything current. At the <br>> same time I can get rid of some excess code as I went through a few <br>> iterations to get to this point. There are still a lot of <br>> unaddressed edge conditions and details that need to be thought <br>> through and addressed – but once we reach consensus on the approach <br>> we can start to address them.</tt><br><tt>> <br>> Thinking though the various repos in reverse order.</tt><br><tt>> <br>> OVS</tt><br><tt>> ===</tt><br><tt>> <br>> I would like to change the code to follow the model that Russell <br>> Bryant did in his patches see: <a href="https://github.com/russellb/ovs/">https://github.com/russellb/ovs/</a><br>> commits/chaining</tt><br><tt>> <br>> They have several advantages:</tt><br><tt>> 1. Creates a new table for chaining which should help isolate the <br>> code and make chaining more “atomic” </tt><br><tt>> 2. He follows the port-pair/port-chain model of SFC so integration <br>> should be cleaner</tt><br><tt>> 3. Following the port-pair/port-chain model makes extending the <br>> solution to handle a chain of VNFs fairly easy.</tt><br><tt>> If everyone is good with this I can work this into the patches and rebase.</tt><br><br><tt>You are anticipating where I was looking to go, so I'm on board with</tt><br><tt>this idea.</tt><br><br><tt>> Networking-OVN</tt><br><tt>> ===============</tt><br><tt>> <br>> There is some old code here in plugin.py that I think comes out. <br>> When I added OVN as a SFC Driver there was a lot of code that I <br>> added to networking-ovn that became obsolete. The IDL code would be<br>> modified to follow the port-pair/port-chain. model. The biggest <br>> question I have from your comments is the interface between the <br>> networking-sfc and networking-ovn. I think I agree with you that <br>> networking-ovn should expose an interface that is called by <br>> networking-sfc and that would remove the need to subclass OVNPlugin <br>> in the networking-sfc OVN driver. Is that what you were intending?</tt><br><br><tt>Yes, I was looking at how that subclass could be avoided.</tt><br><br><tt>> Networking-SFC</tt><br><tt>> ==============</tt><br><tt>> <br>> If we follow Russell’s model in OVN/OVS then there very close <br>> alignment with the SFC model and the code will become simpler. Also <br>> removing the OVNPlugin dependency will also clean things up.</tt><br><br><tt>Yes, I was hoping that would be a side effect as well...</tt><br><br><tt>I like all of your proposed ideas and am looking forward to seeing</tt><br><tt>the next iteration. Please feel free to reach out if you need</tt><br><tt>another pair of hands to help with coding...</tt><br><br><tt>Ryan Moats</tt><BR>
</body></html>