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

Navarro, Galo galo at midokura.com
Wed Feb 13 14:49:46 UTC 2013


Following Pino's request I have created a wiki page summarising the
discussion from this thread and adding a bit more detail to the spec.


Feel free to add any other discussion items (I added a "discussion"
section open). I will start working on the backend design next but do
let me know if you'd like to see deeper details or can see other

We probably want to group all API change proposals, if you think
that's useful I'll create a higher level page to group them all.


On 13 February 2013 11:50, Pino de Candia <gdecandia at midokura.com> wrote:
> Hi Galo,
> although there hasn't been a lot of discussion about this feature, let's do
> a write up the design the wiki - then anyone can go look at what the most
> recent proposal is.
> So far we've only discussed API changes, so now let's also kick off the
> discussion of backend implementation. Eventually, there should be a design
> proposal for that, linked off the feature (REST API) page.
> thanks,
> Pino
> --
> Pino de Candia
> Software Engineer, Midokura.com
> On Wednesday, February 13, 2013 at 12:11 AM, Pino de Candia wrote:
> On Tuesday, February 12, 2013 at 6:49 PM, Guillermo Ontañón wrote:
> On Tue, Feb 12, 2013 at 3:09 PM, Navarro, Galo <galo at midokura.com> wrote:
> Yes, all entries regardless of source. I agree that it'd be desirable
> to have a type. Re. TTL I'd probably put an expiration time when the
> entry is added since we'll probably have expiration also for
> non-snooped entries. If the TTL varies based on type, the ARP cache
> impl can set different values when adding the entry. This is more of
> an implementation detail but should we worry about hosts running
> midonet having significant time differences?
> Good point, I don't think it's necessary, it would work as the ArpTable in
> the router does: the node that writes the entry is in charge of expiration.
> If the node shuts down, the entry is automatically removed by zookeeper
> (it's an ephemeral node).
> BTW, this just made think, would it make sense to expose other pieces of
> state such as the router's ArpTable or the bridge's MacLearningTable through
> the REST API?
> Rossella recently wrote a proposal to extend the API to read/write the
> Bridge's MAC table.
> It seems that if we're adding an ArpTable to the bridge, and exposing it via
> the API it should be easy to extend the Router's ArpTable and use the code
> for both.
> That would leave the router's RoutingTable, which is in a single ZK
> directory, but it's not exposed via the API. Definitely worth doing though.
> -Pino
> Cheers,
> -- Guillermo Ontañón

More information about the MidoNet-dev mailing list