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

Guillermo Ontañón guillermo at midokura.jp
Tue Feb 12 10:14:16 UTC 2013


Hi Galo,

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


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.

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



-- 
-- Guillermo Ontañón
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.midonet.org/pipermail/midonet-dev/attachments/20130212/3ba800d6/attachment.html>


More information about the MidoNet-dev mailing list