<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 11/08/2012 03:33 PM, Bob Melander (bmelande) wrote:
    <blockquote
cite="mid:A6227CA8D0E9FF419CC5FE7BA9EC25A30DFAD27D@xmb-aln-x13.cisco.com"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <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: 0px; font: 12px Helvetica;"><font
            class="Apple-style-span" face="Calibri" size="3">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.</font></p>
      </div>
    </blockquote>
    <br>
    Yay! VRRP will save endless amount of problems with the HA that we
    have the with the layer 3 agents. It would be great if we could add
    an open source solution and it would be beneficial for OpenStack as
    a whole.<br>
    <br>
    <blockquote
cite="mid:A6227CA8D0E9FF419CC5FE7BA9EC25A30DFAD27D@xmb-aln-x13.cisco.com"
      type="cite">
      <div>
        <p style="margin: 0px; font: 12px Helvetica;"><font
            class="Apple-style-span" face="Calibri" size="3"> 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.</font></p>
      </div>
    </blockquote>
    <br>
    Agreed. This is just a matter of implementing the API's and this
    could be done today.<br>
    <br>
    <blockquote
cite="mid:A6227CA8D0E9FF419CC5FE7BA9EC25A30DFAD27D@xmb-aln-x13.cisco.com"
      type="cite">
      <div>
        <p style="margin: 0.0px 0.0px 0.0px 0.0px; font: 12.0px
          Helvetica"><font class="Apple-style-span" face="Calibri"
            size="3"> 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. <br>
          </font></p>
      </div>
    </blockquote>
    <br>
    I think that we need to discuss this further and see how we can
    provide a generic base to build upon. <br>
    <br>
    <blockquote
cite="mid:A6227CA8D0E9FF419CC5FE7BA9EC25A30DFAD27D@xmb-aln-x13.cisco.com"
      type="cite">
      <div>
        <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 class="Apple-style-span" 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>
      </div>
    </blockquote>
    <br>
    It is a nice idea. We just need to ensure that we support the
    current l3 functionality. <br>
    <br>
    <blockquote
cite="mid:A6227CA8D0E9FF419CC5FE7BA9EC25A30DFAD27D@xmb-aln-x13.cisco.com"
      type="cite">
      <div>
        <p style="margin-top: 0px; margin-right: 0px; margin-bottom:
          0px; margin-left: 0px; font: normal normal normal 12px/normal
          Helvetica; ">
          <font class="Apple-style-span" 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 class="Apple-style-span" style="font-family: Calibri;
            font-size: medium; ">What is your view on this?</span></p>
        <div><br>
        </div>
      </div>
      <div>/ Bob</div>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
OpenStack-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
    </blockquote>
    <br>
  </body>
</html>