<div>
                    Hi Galo,
                </div><div><br></div><div>thanks for getting started on this. No comments from me - but I'll follow closely, and encourage others to give feedback (especially the Integration and Gui/Tools teams).</div><div><br></div><div>--Pino</div>
                <div><div><br></div></div>
                 
                <p style="color: #A0A0A8;">On Wednesday, February 6, 2013 at 2:02 PM, Navarro, Galo wrote:</p>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;">
                    <span><div><div><div>Hello, below is an initial proposal for the API changes to support the</div><div>optional Bridge ARP cache. You can see further details at</div><div><a href="https://trello.com/card/bridge-arp-cache/510b93ac787666573800291f/24">https://trello.com/card/bridge-arp-cache/510b93ac787666573800291f/24</a></div><div>but I'm copying the requirements below</div><div><br></div><div>* DTO changes:</div><div><br></div><div>DtoArpCacheEntry (new) to represent an IP-MAC assoc., has properties:</div><div>- IPv4 IP</div><div>- MAC mac</div><div><br></div><div>DtoBridge, add property to enable/disable the usage of the ARP cache.</div><div>- boolean arpCacheEnabled</div><div>- Q: if ARP reply snooping is implemented, should disabling the arp</div><div>cache also stop snooping on ARP replies? If so, should the cache be</div><div>deleted or just be left to stale?</div><div><br></div><div>All new properties should also have the associated getters and setters.</div><div><br></div><div>* ZK path:</div><div><br></div><div>/bridges/[bridgeId]/arp_cache</div><div><br></div><div>* Operations:</div><div><br></div><div>GET all entries:</div><div>- against /bridges/[bridgeId]/arp_cache</div><div>- returns a Collection<DtoArpCacheEntry> that represents the entries</div><div>of the ARP cache on the bridge with id bridgeId.</div><div><br></div><div>PUT an entry:</div><div>- against /bridges/[bridgeId]/arp_cache, adds or replaces an entry</div><div>- returns the new entry</div><div><br></div><div>DELETE an entry</div><div>- against /bridges/[bridgeId]/arp_cache, removes the entry if exists.</div><div><br></div><div>Not sure if we also want:</div><div><br></div><div>DELETE all entries (if it's needed)</div><div>- against /bridges/[bridgeId]/arp_cache, removes ALL the entries.</div><div><br></div><div><br></div><div>------------------------------------------------------------------------------------------------</div><div><br></div><div>* Feature description</div><div><br></div><div>The Virtual Bridge implements an (optional) ARP cache.</div><div>NOTE: IPv4 only.</div><div><br></div><div>When the bridge detects an ARP request, if the reply can be generated</div><div>from its ARP cache, it does so and sends it as a unicast to the source</div><div>of the request. Otherwise, the request is forwarded according to</div><div>normal bridging rules.</div><div><br></div><div>Population of the ARP cache may be accomplished via:</div><div>- the REST API (high priority)</div><div>- snooping on ARP replies (low priority)</div><div><br></div><div>* Core team responsibilities</div><div>- Propose REST API changes to enable/disable the ARP cache, view its</div><div>contents, manipulate its contents.</div><div>- Design the ZK schema changes (should be backwards compatible)</div><div>- Implement the feature in the API server and Midolman.</div><div><br></div><div>* Integration team responsibilities</div><div>- Collaborate with Core team on API design.</div><div>- Design/Implement ARP cache pre-seeding using OpenStack port/mac/ip</div><div>information.</div><div><br></div><div>* GUI/management team responsibilities</div><div>- What frames/pages need to change?</div><div>- What new pages? One to display the ARP cache contents?</div><div><br></div><div>* Q/A team responsibilities</div><div><br></div><div>- Normal vetting of the software. No new tests needed because this is</div><div>an optimization that should not be noticed at a user/functional level</div><div>in OpenStack.</div><div><br></div><div>* Schedule</div><div>- Agree on API changes by Feb. 11</div><div>- Core team delivers untested implementation by Feb 18</div><div>- Core team completes tests by Feb. 25</div><div>- Integration team completes integration changes (Diyari/Grizzly) by Feb. 25</div><div>- QA vets release by Mar. 1</div><div><br></div><div><br></div><div>Thanks!</div><div>Galo</div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div>
                    <br>
                </div>