[MidoNet-dev] API proposal - Optional Bridge ARP Cache

Pino de Candia gdecandia at midokura.com
Wed Feb 6 13:14:49 UTC 2013


Hi Galo, 

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).

--Pino 


On Wednesday, February 6, 2013 at 2:02 PM, Navarro, Galo wrote:

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130206/973e7483/attachment-0001.html>


More information about the MidoNet-dev mailing list