On Sat, Nov 07, 2015 at 10:22:03PM -0800, Han Zhou wrote: > I noticed that the "mac" field of Logical_Router_Port must be set the same > as mac address in "addresses" field of the peer patch port in Logical_Port > table. At least this is what has been verified in my test setup and also in > ovn.at test cases.
It's true. > If this is a constraint I wonder if it is better to ensure in schema, e.g. > removing the mac field in Logical_Router_Port table, and always use mac > information from its peer lswitch patch port when needed. I'd like to > propose a patch for this. While working on the code, I realized that this > might be for the case of peering lrouter ports. In that case, however, mac > is not really needed because no ARP would be sent between peering lrouter > ports. Please correct me if I am wrong. I was about to raise that as an issue, but I guess you're right. > If for any reason this field is required and must be set the same as > peering lswitch patch port, should this be documented somewhere to avoid > confusion? We should definitely do one or the other. 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), 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. > Another question related to the patch port is, in Logical_Port the key is > name, while in Logical_Router_Port the key is uuid, which indicates the > router-option in peer lswitch patch port must be set with uuid rather than > name. Is there any special considerations? If not, could you review my > patch for this (tests passed): > > http://openvswitch.org/pipermail/dev/2015-November/061961.html It seems fine, I'll look at the next version soon. _______________________________________________ dev mailing list dev@openvswitch.org http://openvswitch.org/mailman/listinfo/dev
