Hi,<div><br></div><div>As Dan said, the mixin approach was mainly adopted for quickly achieving a solution for providing L3 forwarding, plus SNAT and DNAT capabilities in order to get closer to parity with nova network. This approach, despite being easy to implement and understand, comes with several drawbacks. Most importantly it increases the complexity of the resulting plugin, which will have to manage plenty of features, and also makes it harder to support different technologies.</div>
<div><br></div><div>I think it makes sense, during the Grizzly timeframe, to split the l3 functionality in its own plugin. I will be happy to do this during the Grizzly-2 milestone, leveraging the work Eugene is doing for the Grizzly-1 milestone. As I have dealt with Quantum API and DB layers in the past, I should comfortable enough in doing this change. The current Quantum L3 agent will be able to keep working as it is doing now, even if L3 feature is moved into a separate plugin.</div>
<div><br></div><div>As a note, methods such as process_l3_create, process_l3_update, or filter_nets_l3, are needed for allowing the core L2 plugin to deal with extensions to the L2 API resources introduced by the L3 plugin. We are already aware that they are not very nice in the overall architecture, as ideally one would like extensions to process the resource they're extending a pipeline-like fashion. Bob Kukura was aiming at doing some work in this direction.</div>
<div><br></div><div>Also, I would like to mention that we are moving L3 APIs into the 'core'. Just to be clear - the 'core API' is different from the 'core' plugin. We regard as 'core API' the minimum set of APIs that every Quantum deployment needs to provide. Everything else is an extension. The implications on the plugin layer, if we split L2 and L3 plugin, is that each deployment should have at least two plugins. </div>
<div><br></div><div>Salvatore</div><div><br><br><div class="gmail_quote">On 9 November 2012 12:42, Bob Melander (bmelande) <span dir="ltr"><<a href="mailto:bmelande@cisco.com" target="_blank">bmelande@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



<div style="word-wrap:break-word">
<div style="font-family:Calibri,sans-serif;font-size:14px">Ok, I'm willing to work on this and I've created a blueprint to kick it off (<a href="https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin" target="_blank">https://blueprints.launchpad.net/quantum/+spec/quantum-l3-routing-plugin</a>)</div>

<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px">I too think VRRP (and some other features) would be nice to add. However, the first steps would be to take the inherited mixin and transform that into a plugin. That ought to be possible with
 fairly limited effort. Though there are some dependencies that need to be sorted out. In particular, core plugin methods like <span style="font-family:Helvetica;font-size:12px"> <span style="font:normal normal normal 12px/normal Courier">create_network(…)</span></span>make
 calls to mixin functions such as <span style="font-family:Helvetica;font-size:12px"><span style="font:12.0px Courier">_process_l3_create(…), _extend_network_dict_l3(…), _process_l3_update(…)</span><span style="font:12.0px Courier">:</span></span></div>

<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier;min-height:14px">
<br>
</p>
<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier">
self._process_l3_create(context, network['network'], net['id'])</p>
<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier">
…</p>
<p style="font-family:Calibri,sans-serif;font-size:14px;margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Courier">
self._extend_network_dict_l3(context, net)</p>
<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px">This does not immediately map to the service insertion schematic:</div>
<div style="font-family:Calibri,sans-serif;font-size:14px">
<p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica"><img src="cid:2E546006-960D-4222-A4CA-EE7A5E73431B" alt="ServiceIntegration.jpg" type="image/png"></p>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px">/ Bob</div>
<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<div style="font-family:Calibri,sans-serif;font-size:14px"><br>
</div>
<span style="font-size:14px;font-family:Calibri,sans-serif">
<div style="border-right:medium none;padding-right:0in;padding-left:0in;padding-top:3pt;text-align:left;font-size:11pt;border-bottom:medium none;font-family:Calibri;border-top:#b5c4df 1pt solid;padding-bottom:0in;border-left:medium none">

<span style="font-weight:bold">From: </span>Dan Wendlandt <<a href="mailto:dan@nicira.com" target="_blank">dan@nicira.com</a>><br>
<span style="font-weight:bold">Reply-To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><br>
<span style="font-weight:bold">Date: </span>torsdag 8 november 2012 21:03<br>
<span style="font-weight:bold">To: </span>OpenStack Development Mailing List <<a href="mailto:openstack-dev@lists.openstack.org" target="_blank">openstack-dev@lists.openstack.org</a>><div class="im"><br>
<span style="font-weight:bold">Subject: </span>Re: [openstack-dev] Quantum L3 router, mixin or plugin?<br>
</div></div>
<div><br>
</div>
<div>
<div><div class="im">Yes, being able to implement the L3 stuff independent of the core plugin (rather than as a mixin, tightly bound to the core plugin) was always the plan.  We did it as a mix-in for Folsom, as we didn't have time for the multi-service framework, but wanted
 to deliver L3 capabilities.  You can see the blueprint for this, which is targeted at G-1: <span style="white-space:pre-wrap">
</span>
<div><br>
</div>
</div><div class="im"><div>I don't think anyone has signed up to do the work to port the L3 API to this new framework, so feel free to create a blueprint and add a dependency to the above blueprint.  </div>
<div><br>
</div>
<div>dan<br>
<div><br>
<div class="gmail_quote">On Thu, Nov 8, 2012 at 5:33 AM, Bob Melander (bmelande) <span dir="ltr">
<<a href="mailto:bmelande@cisco.com" target="_blank">bmelande@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="font-size:14px;font-family:Calibri,sans-serif;word-wrap:break-word">
<div>In the wake of the recent discussion about service insertion, which seems to have landed in a decision to make each type of service (like LBaaS, FW, …) a separate plugin, I want to raise the issue whether this approach shouldn't also be adopted for L3
 router functionality. This is not the case now, where instead the server side is implemented as a L3_NAT_db_mixin class that basically each plugin inherits. The actual routing is implemented through the separate L3 agent (L3NATagent class) that relies on linux
 namespaces, the kernel IP forwarding functionality and IP tables.</div>
<div><br>
</div>
<div>
<p style="margin:0.0px 0.0px 0.0px 0.0px;font:12.0px Helvetica"><font size="3" face="Calibri">My concern about this is the following: Suppose one would like to replace (or complement) that router implementation with something else, e.g., use a separate hardware-based
 router or add additional features like VRRP to the implementation. As long as the changes can be contained within the l3 agent (while honoring the normal interface), it is fairly simple to just replace the default one with the extended l3 agent in the deployment.
 However, if the desired functionality requires changes to the "server side", i.e.,  the L3_NAT_db_mixin class, the situation gets much more tricky since the mixin is essentially baked into the core plugin. </font></p>

<div><br>
</div>
</div>
<div>
<p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Helvetica">
<font face="Calibri" size="3">A way around this problem could be to provide the l3 routing functionality as a separate plugin, just as there will be separate plugins for LBaaS, FW, etc. With L3 routing also as a separate plugin, it seems to me it would be simpler
 to provide different such implementations, largely independent of (L2) core plugin but also to introduce additional L3 specific extensions.</font></p>
<p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Helvetica">
<font face="Calibri" size="3"><br>
</font></p>
<p style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;font:normal normal normal 12px/normal Helvetica">
<span style="font-family:Calibri;font-size:medium">What is your view on this?</span></p>
<span><font color="#888888">
<div><br>
</div>
</font></span></div>
<span><font color="#888888">
<div>/ Bob</div>
</font></span></div>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org" target="_blank">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br>
</blockquote>
</div>
<br>
<br clear="all">
<div><br>
</div>
-- <br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
Dan Wendlandt 
<div>Nicira, Inc: <a href="http://www.nicira.com" target="_blank">www.nicira.com</a><br>
<div>twitter: danwendlandt<br>
~~~~~~~~~~~~~~~~~~~~~~~~~~~<br>
</div>
</div>
<br>
</div>
</div>
</div></div>
</div>
</span>
</div>

<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>