[ovs-dev] Questions about lrouter patch ports in ovn-nb schema

Ben Pfaff blp at ovn.org
Tue Dec 1 18:34:21 UTC 2015


On Mon, Nov 30, 2015 at 11:02:29PM -0800, Han Zhou wrote:
> Hi Ben,
> 
> On Tue, Nov 24, 2015 at 6:12 PM, Ben Pfaff <blp at ovn.org> wrote:
> > I'm having trouble figuring out which one we should do.  The reason that
> > I'm torn between choices is because of layering.  I like the way that,
> > currently, the switch and router datapaths are (almost) independent of
> > each other, in the sense that they don't have to know anything about
> > what they're attached to.  However, we've already got one violation of
> > this principle: logical routers statically discover MAC-IP bindings on
> > their attached switches.  For now, that's pretty much necessary, since
> > logical routers don't support ARP yet (I'm fixing that, don't worry),
> 
> By "support ARP" do you mean logical routers broadcast ARP requests to
> lswitch ports and then process ARP replies (from the owner of the IP)
> to get IP-MAC bindings?
> In such case even if this kind of dynamic ARP is supported, it would
> still be valuable to continue supporting the static MAC-IP bindings,
> which is the major scenario of CMS such as openstack, where IP-MAC
> binding is known during VM provisioning (and similar use case for
> containers). I think dynamic ARP introduce higher costs, and requires
> periodical refreshing, so it is better to be triggered only when
> static binding is not available.
> 
> Or do you mean any other kind of ARP support?

I do mean what you thought.  ARP is more or less necessary because
IP-MAC bindings aren't always statically available, especially when
physical infrastructure is brought into a logical network.

I don't think we'd ever discontinue the static MAP-IP bindings.  They
are a valuable optimization.  If we decide that strict layering is
important, then they could be implemented by having logical routers send
out ARP requests and then having the logical switches send the ARP
replies.  The ARP would never travel over a physical network in this
case.

However, as we continue our discussion here, I'm leaning more and more
against worrying about layering issues, at least in the current context.

> > but in the long run we could eliminate it.  Or we could decide that this
> > idea of layering and separation is not valuable (in this case); I don't
> > have a strong opinion yet.
> >
> 
> Thanks for this background of the choices. I think it is ok to keep
> current implementation until we figure out which option is better.

OK.



More information about the dev mailing list