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.

[...]

> @@ -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.

[...]

> +      <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.
        
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev

Reply via email to