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

Navarro, Galo galo at midokura.com
Wed Feb 6 13:02:40 UTC 2013


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


More information about the MidoNet-dev mailing list