On Thu, Feb 19, 2015 at 11:45:08PM +0100, Thomas Graf wrote:
> On 02/19/15 at 11:16am, Ben Pfaff wrote:
> > diff --git a/ovn/ovn-nb.ovsschema b/ovn/ovn-nb.ovsschema
> > new file mode 100644
> > index 0000000..4c29562
> > --- /dev/null
> > +++ b/ovn/ovn-nb.ovsschema
>
> The schema below has some whitespace / tab mixups.
Oops. I've run untabify now.
> > @@ -0,0 +1,63 @@
> > +{
> > + "name": "OVN_Northbound",
> > + "tables": {
> > + "Logical_Switch": {
> > + "columns": {
> > + "external_ids": {
> > + "type": {"key": "string", "value": "string",
> > + "min": 0, "max": "unlimited"}}}},
> > + "Logical_Port": {
> > + "columns": {
> > + "switch": {"type": {"key": {"type": "uuid",
> > + "refTable": "Logical_Switch",
> > + "refType": "strong"}}},
> > + "router_port": {"type": {"key": {"type": "uuid",
> > + "refTable":
> > "Logical_Router_Port",
> > + "refType": "strong"},
> > + "min": 0,
> > + "max": 1}},
>
> What is the reason to hook the Logical_Router_Port to a Logical_Port
> and not to the Logical_Switch directly? It seems like the port_security
> does not apply to routers and the state should also be "up" at all
> times.
I've switched this back and forth a couple of times. Maybe I'll put
it back again.
The one feature that I want to make sure can apply to router ports is
ACLs. That isn't contingent on a Logical_Router_Port being a
Logical_Port, though, so it's not a deal-breaker.
> [...]
>
> > + <p>
> > + Following are not well thought out:
> > + </p>
> > +
> > + <dl>
> > + <dt><code>learn</code></dt>
> > +
> > + <dt><code>conntrack</code></dt>
> > +
> > + <dt><code>with(<var>field</var>=<var>value</var>) {
> > <var>action</var>, </code>...<code> }</code></dt>
> > + <dd>execute <var>actions</var> with temporary changes to
> > <var>fields</var></dd>
> > +
> > + <dt><code>dec_ttl { <var>action</var>, </code>...<code> } {
> > <var>action</var>; </code>...<code>}</code></dt>
> > + <dd>
> > + decrement TTL; execute first set of actions if
> > + successful, second set if TTL decrement fails
> > + </dd>
> > +
> > + <dt><code>icmp_reply { <var>action</var>, </code>...<code>
> > }</code></dt>
> > + <dd>generate ICMP reply from packet, execute
> > <var>action</var></dd>
>
> Possible useful addition could be arp_respond to implement the L2 pop
> of OpenStack.
I thought that was in there, but now I see that it isn't. I guess
that never made it off my whiteboard. I'll add it.
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
