[MidoNet-dev] API proposal - Optional Bridge ARP Cache
guillermo at midokura.jp
Tue Feb 12 10:14:16 UTC 2013
Looks good, just one comment below,
On Wed, Feb 6, 2013 at 2:02 PM, Navarro, Galo <galo at midokura.com> wrote:
> Hello, below is an initial proposal for the API changes to support the
> optional Bridge ARP cache. You can see further details at
> 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:
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
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.
> * 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
> * 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.
> - QA vets release by Mar. 1
-- Guillermo Ontañón
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the MidoNet-dev