<div dir="ltr">Hi Galo,<div class="gmail_extra"><br></div><div class="gmail_extra">Looks good, just one comment below,</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Feb 6, 2013 at 2:02 PM, Navarro, Galo <span dir="ltr"><<a href="mailto:galo@midokura.com" target="_blank">galo@midokura.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello, below is an initial proposal for the API changes to support the<br>
optional Bridge ARP cache. You can see further details at<br>
<a href="https://trello.com/card/bridge-arp-cache/510b93ac787666573800291f/24" target="_blank">https://trello.com/card/bridge-arp-cache/510b93ac787666573800291f/24</a><br>
but I'm copying the requirements below<br>
<br>
* DTO changes:<br>
<br>
DtoArpCacheEntry (new) to represent an IP-MAC assoc., has properties:<br>
- IPv4 IP<br>
- MAC mac<br>
<br>
DtoBridge, add property to enable/disable the usage of the ARP cache.<br>
- boolean arpCacheEnabled<br>
- Q: if ARP reply snooping is implemented, should disabling the arp<br>
cache also stop snooping on ARP replies? If so, should the cache be<br>
deleted or just be left to stale?<br>
<br>
All new properties should also have the associated getters and setters.<br>
<br>
* ZK path:<br>
<br>
/bridges/[bridgeId]/arp_cache<br></blockquote><div><br></div><div style><br></div><div style>Would snooped entries show up here too? If so, DtoArpCacheEntry may need field(s) to indicate the type of entry and the time-to-live for snooped ones.</div>
<div style><br></div><div style>One more thing, under this directories, would entries have a uuid or be identified by the IP address. I'd go for the latter to eliminate the possibility of duplicates.</div><div style><br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
* Operations:<br>
<br>
GET all entries:<br>
- against /bridges/[bridgeId]/arp_cache<br>
- returns a Collection<DtoArpCacheEntry> that represents the entries<br>
of the ARP cache on the bridge with id bridgeId.<br>
<br>
PUT an entry:<br>
- against /bridges/[bridgeId]/arp_cache, adds or replaces an entry<br>
- returns the new entry<br>
<br>
DELETE an entry<br>
- against /bridges/[bridgeId]/arp_cache, removes the entry if exists.<br>
<br>
Not sure if we also want:<br>
<br>
DELETE all entries (if it's needed)<br>
- against /bridges/[bridgeId]/arp_cache, removes ALL the entries.<br>
<br>
<br>
------------------------------------------------------------------------------------------------<br>
<br>
* Feature description<br>
<br>
The Virtual Bridge implements an (optional) ARP cache.<br>
NOTE: IPv4 only.<br>
<br>
When the bridge detects an ARP request, if the reply can be generated<br>
from its ARP cache, it does so and sends it as a unicast to the source<br>
of the request. Otherwise, the request is forwarded according to<br>
normal bridging rules.<br>
<br>
Population of the ARP cache may be accomplished via:<br>
- the REST API (high priority)<br>
- snooping on ARP replies (low priority)<br>
<br>
* Core team responsibilities<br>
- Propose REST API changes to enable/disable the ARP cache, view its<br>
contents, manipulate its contents.<br>
- Design the ZK schema changes (should be backwards compatible)<br>
- Implement the feature in the API server and Midolman.<br>
<br>
* Integration team responsibilities<br>
- Collaborate with Core team on API design.<br>
- Design/Implement ARP cache pre-seeding using OpenStack port/mac/ip<br>
information.<br>
<br>
* GUI/management team responsibilities<br>
- What frames/pages need to change?<br>
- What new pages? One to display the ARP cache contents?<br>
<br>
* Q/A team responsibilities<br>
<br>
- Normal vetting of the software. No new tests needed because this is<br>
an optimization that should not be noticed at a user/functional level<br>
in OpenStack.<br>
<br>
* Schedule<br>
- Agree on API changes by Feb. 11<br>
- Core team delivers untested implementation by Feb 18<br>
- Core team completes tests by Feb. 25<br>
- Integration team completes integration changes (Diyari/Grizzly) by Feb. 25<br>
- QA vets release by Mar. 1<br>
<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888">Galo<br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div dir="ltr">-- Guillermo Ontañón</div>
</div></div>