<div>
                    Ciao Rossella,
                </div><div><br></div><div>although there hasn't been a lot of discussion, let's assume these REST API changes are good enough for now. Please write up the current proposal in the wiki so that we don't have to search e-mail and parse an entire thread to understand what the current thinking is.</div><div><br></div><div>Also, let's kick off the backend design discussion.</div><div><br></div><div>thanks,</div><div>Pino</div>
                <div><div><br></div>-- <br>Pino de Candia<br>Software Engineer, Midokura.com<div><br></div></div>
                 
                <p style="color: #A0A0A8;">On Wednesday, February 6, 2013 at 1:51 PM, Pino de Candia wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div>
                <div>I have a question going back to requirements. Is our goal to provide the API client with a mechanism that:</div><div>A) allows them to reduce flooding on the bridge?</div><div>B) allows them to completely eliminate flooding on the bridge?</div><div><br></div><div>I think we should be aiming for B - I'd like to hear other opinions. My feeling is that saying this to customers is a selling point: "you can configure your bridges so that they'll never flood any traffic".</div><div><br></div><div>After writing up this e-mail, I think B can be achieved without any additional work. But please check my reasoning because if something's missing I'd still like to achieve B.</div><div><br></div><div>Here's how we can enable B:</div><div>1) allow customers to pre-seed the mac-table with permanent entries - they don't expire and can't be displaced by learned entries.</div><div>2) normal mac-learning is still enabled (if the API client doesn't pre-seed, hosts on the bridge can still receive traffic as long as they occasionally send a packet so that the learned mac-port entry is not forgotten).</div><div>3) client uses a post-bridging chain rule on the Bridge to drop anything whose L2 destination is BCAST.</div><div>4) client uses a post-bridging chain rule on the Bridge to drop anything whose L2 destination is a MCAST or is an unlearned MAC (the packet would be flooded in both cases).</div><div><br></div><div>Only #1 requires an API change. Everything else is already supported.</div><div><br></div><div>#4 can be accomplished, but we haven't tried it, by using a rule with:</div><div>- a condition that matches outPortIds={BridgeId} - note that the "flood" action is encoded by setting the outPortId to the BridgeId.</div><div>- a DROP action.</div><div><br></div><div>#3 and #4 use post-bridging rules so that the Proxy ARP feature gets a chance before the packet is discarded.</div><div><br></div><div>thanks,</div><div>Pino</div><div><br></div>
                  
                <p style="color: #A0A0A8;">On Wednesday, February 6, 2013 at 1:10 PM, Rossella Sblendido wrote:</p><blockquote type="cite"><div>
                    <span><div><div>
    
    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
    
    
    <div>Hi Pino,<br>
      <br>
      thanks a lot for your feedback. My comments inline.<br>
      <br>
      Rossella<br>
      <br>
      On 2/6/13 11:55 AM, Pino de Candia wrote:<br>
    </div><blockquote type="cite"><div>
      <div> Hi Rossella, </div>
      <div><br>
      </div>
      <div>thanks for starting this discussion so promptly.</div>
      <p style="color: #A0A0A8;">On Wednesday, February 6, 2013 at 1:34
        AM, Rossella Sblendido wrote:</p><blockquote type="cite"><div>
        <span>
          <div>
            <div>
              <meta http-equiv="content-type" content="text/html;
                charset=UTF-8">
              Hi devs,<br>
              <br>
              I'd like to start the discussion regarding the population
              of the Mac-learning table for a bridge using the API. <br>
              You can have a look at the requirements <a moz-do-not-send="true" href="https://trello.com/card/pre-seed-mac-table-via-rest-api/510b93ac787666573800291f/25">here</a>,
              I'm copying them at the bottom to facilitate the
              discussion.<br>
              <br>
              Here is my proposal:<br>
              <br>
              <b>API changes</b>:<br>
              <ol>
                <li>We need to have a new DTO to represent the
                  MAC-vPortId association, something like:<br>
                </li>
              </ol>
              <p>        public class DtoMacPort {<br>
                                private UUID portId;<br>
                                private MAC mac;<br>
                                // getters<br>
                                // setters<br>
              </p>
              <p>        }<br>
              </p>
              <ol>
                <li>A GET against bridges/bridge_id/macPort will return
                  a Collection<DtoMacPort> representing all the
                  entries of the Mac-learning table of the bridge whose
                  id is bridge_id.</li>
              </ol>
            </div>
          </div>
        </span></div></blockquote><div>Is that actual run-time Mac-table contents at that moment in
        time? Or is it just the list of pre-seeded DtoMacPort?</div>
    </div></blockquote>
    The actual run-time Mac-table content.<br><blockquote type="cite"><div>
      <div> </div><blockquote type="cite"><div><span>
          <div>
            <div>
              <ol>
                <li>A PUT of a DtoMacPort object against
                  bridges/bridge_id/macPort will add a new entry to the
                  Mac-learning table, if there's already an entry with
                  the same Mac, this will be overwritten.</li>
              </ol>
            </div>
          </div>
        </span></div></blockquote><div>PUT does not return a DTO to the client. Therefore there's no
        way of passing the DTO's URI back to the client (in the HATEOAS
        style) - the client could use a template to generate the URI,
        but I don't like that being the only option.</div>
      <div><br>
      </div>
      <div>Instead, can we say that the first time the client wants to
        set the vport for a specific MAC, they do a POST. This will
        return a DTO that includes the URI of the object, which will be
        needed for update and deletion. If you do a POST and there's
        already a mac-port entry for that mac, you get an error.</div>
    </div></blockquote>
    Pino, my idea was to use <span>bridges/bridge_id/macPort as URI.
      The main DTO is a </span><span> Collection<DtoMacPort> and
      we do a PUT or DELETE to add or remove and item from the
      collection.</span><br>
    <br><blockquote type="cite"><div>
      <div><br>
      </div>
      <div>Subsequently, if the client wants to change a mac's vport,
        they set the new vport UUID in the dto and PUT it to the server.</div>
      <div><br>
      </div>
      <div>If a client does not know if this is the first time the mac's
        vport has been set (doesn't know whether to use PUT or POST),
        then they have two options:</div>
      <div>- GET as in #1 (lists all the DtoMacPort)</div>
      <div>- Do a GET on a template /bridges/bridge_id/macPort/_mac_.
        We're using templates in other places for similar reasons. The
        templates are provided inside DTOs (so that we can evolve them).
        Where should this template be provided?</div>
      <div><br>
      </div><blockquote type="cite"><div><span>
          <div>
            <div>
              <ol>
                <li>A DELETE of a DtoMacPort object against
                  bridges/bridge_id/macPort will remove the entry whose
                  MAC=DtoMacPort.getMac() from the Mac-learning table of
                  the bridge whose id is bridge_id<br>
                </li>
              </ol>
            </div>
          </div>
        </span></div></blockquote><div>The DELETE will be against the DtoMacPort.getURI() right? And
        the URI is probably going to be /bridges/bridge_id/macPort/mac.</div>
      <div><br>
      </div>
      <div>However, this has the following consequence, any DTO (even
        outdated) can be used to DELETE the mac-port entry for that mac.</div>
    </div></blockquote>
    We can add a check for that.<br><blockquote type="cite"><div><blockquote type="cite"><div><span>
          <div>
            <div>
              <p>Do we need a method to check if a specific MAC is
                already in the map?<br>
              </p>
              <b>ZK changes</b>:<br>
              <br>
              We store the MAC/vPortId association in ZK under:<br>
              <br>
              bridges/bridge_id/mac_ports/<br>
              <br>
              We use a ReplicatedMap, whose key is the Mac and value is
              the UUID of the port. ReplicatedMap as the name says is a
              map that is stored both in memory and in ZK. We load it
              when we initialize it and we keep it in sync with ZK.<br>
              In our code any entry (Mac1, inPort1) in the Mac-learning
              table gets deleted when the flows count whose sourceMac =
              Mac1  and ingressPort = inPort1 reaches 0. My
              interpretation of permanent entries is that we don't
              modify them taking into account the flows count, hopefully
              I'm not wrong. <br>
              To make the entry permanent I'd add a boolean in the
              ReplicatedMap, isPermanent. If isPermanent=true then the
              entry cannot be removed.<br>
            </div>
          </div>
        </span></div></blockquote><div>I would hold off on the discussion of the API back-end
        implementation so we can focus on the API design. The API design
        is of interest to a wider audience than the back-end
        implementation, so I would have the latter discussion in a
        separate thread (and only after the API design has been agreed).</div>
    </div></blockquote>
    Agreed<br><blockquote type="cite"><div>
      <div><br>
      </div>
      <div>Caveat: I think it's reasonable that during the API design
        discussion someone says "That API won't work because there's no
        way the back-end can support it." But it becomes a question of
        feasibility, not converging on a specific back-end design.</div>
      <div><br>
      </div>
      <div>cheers,</div>
      <div>Pino</div><blockquote type="cite"><div><span>
          <div>
            <div> <br>
              <br>
------------------------------------------------------------------------------------------------------------------<br>
              <meta http-equiv="content-type" content="text/html;
                charset=UTF-8">
              <div attr="desc">
                <div style="display: block;">
                  <p><strong>Feature description</strong><br>
                    The API allows populating the virtual bridge's
                    mac-learning table with permanent entries. This is
                    used to avoid flooding the bridge for use-cases
                    where the vport/mac pairs are known in advance.</p>
                  <p><strong>Core team responsibilities</strong><br>
                    - Propose API changes to expose the MAC-learning
                    table for viewing and manipulating.<br>
                    - Design ZK changes (should be backward compatible)<br>
                    - Implement API server changes and Midolman changes.</p>
                  <p><strong>Integration team responsibilities</strong><br>
                    - Modify OpenStack integration to pass OS vport/mac
                    pair information as Mac-table entries at instance
                    launch.</p>
                  <p><strong>GUI/management team</strong><br>
                    - Define existing page that need to change (none?)<br>
                    - Define new pages - one to display the mac-table
                    contents?<br>
                    - Implement the new pages.</p>
                  <p><strong>QA team responsibilities</strong><br>
                    - Normal vetting of a software version. The changes
                    are not user-visible because this is an
                    optimization.</p>
                  <p><strong>Schedule</strong><br>
                    - Agree on REST API changes by Feb. 11<br>
                    - Core team delivers implementation prototype by
                    Feb. 18<br>
                    - Core team completes testing by Feb. 25.<br>
                    - Integration team completes changes to
                    Grizzly/Diyari by Feb. 25.<br>
                    - QA team approves by March 1.</p>
                </div>
              </div>
              <br>
            </div>
          </div>
        </span> </div></blockquote><div> <br>
      </div>
    </div></blockquote><br>
    

</div></div></span>
                  
                  
                  
                  
                </div></blockquote><div>
                    <br>
                </div>
            </div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>