<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>Ryan,</div>
<div><br>
</div>
<div>Thanks for taking a look at these - really appreciate it. I will work on the rebasing this week and get everything current. At the same time I can get rid of some excess code as I went through a few iterations to get to this point. There are still a lot
of unaddressed edge conditions and details that need to be thought through and addressed – but once we reach consensus on the approach we can start to address them.</div>
<div><br>
</div>
<div>Thinking though the various repos in reverse order.</div>
<div><br>
</div>
<div>OVS</div>
<div>===</div>
<div><br>
</div>
<div>I would like to change the code to follow the model that Russell Bryant did in his patches see: <a href="https://github.com/russellb/ovs/commits/chaining">https://github.com/russellb/ovs/commits/chaining</a></div>
<div><br>
</div>
<div>They have several advantages:</div>
<ol>
<li>Creates a new table for chaining which should help isolate the code and make chaining more “atomic” </li><li>He follows the port-pair/port-chain model of SFC so integration should be cleaner</li><li>Following the port-pair/port-chain model makes extending the solution to handle a chain of VNFs fairly easy.</li></ol>
<div>If everyone is good with this I can work this into the patches and rebase.</div>
<div><br>
</div>
<div>Networking-OVN</div>
<div>===============</div>
<div><br>
</div>
<div>There is some old code here in plugin.py that I think comes out. When I added OVN as a SFC Driver there was a lot of code that I added to networking-ovn that became obsolete. The IDL code would be modified to follow the port-pair/port-chain. model. The
biggest question I have from your comments is the interface between the networking-sfc and networking-ovn. I think I agree with you that networking-ovn should expose an interface that is called by networking-sfc and that would remove the need to subclass OVNPlugin
in the networking-sfc OVN driver. Is that what you were intending?</div>
<div><br>
</div>
<div>Networking-SFC</div>
<div>==============</div>
<div><br>
</div>
<div>If we follow Russell’s model in OVN/OVS then there very close alignment with the SFC model and the code will become simpler. Also removing the OVNPlugin dependency will also clean things up.</div>
<div><br>
</div>
<div><br>
</div>
<div>Regards</div>
<div><br>
</div>
<div>John</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Ryan Moats <<a href="mailto:rmoats@us.ibm.com">rmoats@us.ibm.com</a>><br>
<span style="font-weight:bold">Date: </span>Sunday, May 8, 2016 at 11:23 AM<br>
<span style="font-weight:bold">To: </span>John McDowall <<a href="mailto:jmcdowall@paloaltonetworks.com">jmcdowall@paloaltonetworks.com</a>><br>
<span style="font-weight:bold">Cc: </span>"<a href="mailto:discuss@openvswtich.org">discuss@openvswtich.org</a>" <<a href="mailto:discuss@openvswtich.org">discuss@openvswtich.org</a>>, "<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>"
<<a href="mailto:openstack-dev@lists.openstack.org">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Subject: </span>[OVN] [networking-ovn] [networking-sfc] SFC and OVN<br>
</div>
<div><br>
</div>
<div>
<div>
<p><tt>First, apologies for the cross-posting, but when this topic came up last week,</tt><br>
<tt>I wasn't able to keep track of all the folks that asked to be included in the email,</tt><br>
<tt>so I'm doing a mass post to try and catch everybody that might be interested.</tt><br>
<br>
<tt>Second, John, thank you for stepping forward and mentioning that you've been</tt><br>
<tt>working on code for SFC and OVN!! I took a look at your repos on github.com</tt><br>
<tt>(because I'm a firm believe in NOT re-inventing the wheel) and my initial </tt>
<br>
<tt>comments follow...</tt><br>
<br>
<tt>Networking-SFC (</tt><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_networking-2Dsfc&d=CwMFAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=U1Z58onycTVLkKu5lK1k6MTi8Vx_TRm7AYdfOfjzHKU&s=f0FHv3SjQ4uiHA5szlYScnjrn-3hXOmeL5rvvYeChGY&e="><tt>https://github.com/doonhammer/networking-sfc</tt></a><tt>)</tt><br>
<tt>=============================================================</tt><br>
<br>
<tt>This repo is the cleanest, as I was able to merge the current networking-sfc</tt><br>
<tt>master on top of it with no conflicts. Looking around, I'm not entirely</tt><br>
<tt>comfortable with the idea of networking-sfc making direct calls to the OVN IDL</tt><br>
<tt>in parallel to networking-ovn. I believe a cleaner solution would be to </tt>
<br>
<tt>add the code to configure OVN for SFC to networking-ovn itself, and expose an</tt><br>
<tt>API that the driver code in networking-sfc would call. </tt><br>
<br>
<tt>Networking-OVN (</tt><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_networking-2Dovn&d=CwMFAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=U1Z58onycTVLkKu5lK1k6MTi8Vx_TRm7AYdfOfjzHKU&s=W1GnEuKxO_aoyjJ5aMHM8vA8no-OrpSdP0hSk0AXYe4&e="><tt>https://github.com/doonhammer/networking-ovn</tt></a><tt>)</tt><br>
<tt>=============================================================</tt><br>
<br>
<tt>This repo makes me a bit nervous, as it claims to be 36 commits ahead</tt><br>
<tt>(and 129 commits behind) openstack-master. That's a substantial drift, and</tt><br>
<tt>the first thing I wanted to do was see what merge conflicts might exist when</tt><br>
<tt>I try to merge the current master into it. There are two merge conflicts</tt><br>
<tt>detected in networking_ovn/plugin.py, and given (as I understand it) the</tt><br>
<tt>direction of splitting the networking-ovn monolithic plugin back into ML2</tt><br>
<tt>and L3 service portions, I encourage you to rebase this commit (if you don't</tt><br>
<tt>have time, let me know and I'll see about fixing the merge issue).</tt><br>
<br>
<tt>OVS (</tt><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_doonhammer_ovs&d=CwMFAg&c=V9IgWpI5PvzTw83UyHGVSoW3Uc1MFWe5J8PTfkrzVSo&r=vZ6VUDaavDpfOdPQrz1ED54jEjvAE36A8TVJroVlrOQ&m=U1Z58onycTVLkKu5lK1k6MTi8Vx_TRm7AYdfOfjzHKU&s=H-trbUXmgMIli4e4mi8uGbkTX_BTsXjwn4-qArQiIiU&e="><tt>https://github.com/doonhammer/ovs</tt></a><tt>)</tt><br>
<tt>=======================================</tt><br>
<br>
<tt>This repo also has some drift (in that it is 21 comits ahead and 406 commits</tt><br>
<tt>behind openvswitch master). The merge conflicts I've found here are in</tt><br>
<tt>ovn/ovn-nb.ovsschema and ovn/northd/ovn-northd.c. The ovsschema conflict</tt><br>
<tt>looks like it can be resolved by bumping the micro version of the current master</tt><br>
<tt>and recalculating/inserting the schema checksum. On the other hand, the</tt><br>
<tt>conflicts in ovn-northd.c are a bit more numerous (I count 22 of them as I write</tt><br>
<tt>this). I'm not sure what the easiest way is to get this rebased onto the</tt><br>
<tt>current tip of tree master...</tt><br>
<br>
<tt>The reason I'm interested in the rebasing exercises is I want to get to a set</tt><br>
<tt>of patches that can be publically committed, at which point I (wearing my</tt><br>
<tt>operator hat) can evaluate them to see if they meet our needs for SFC. If you</tt><br>
<tt>need help with the rebasing, I'm happy to work with you...</tt><br>
<br>
<tt>Ryan Moats (regXboi on IRC, jayhawk87 on github)</tt><br>
</p>
</div>
</div>
</span>
</body>
</html>