These files used both tabs and spaces for indentation. Convert all of the tabs to spaces for consistency.
Signed-off-by: Russell Bryant <[email protected]> --- ovn/ovn-architecture.7.xml | 68 ++++----- ovn/ovn-nb.xml | 34 ++--- ovn/ovn-sb.xml | 340 ++++++++++++++++++++++----------------------- 3 files changed, 221 insertions(+), 221 deletions(-) diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml index 9ed162b..10dd1bf 100644 --- a/ovn/ovn-architecture.7.xml +++ b/ovn/ovn-architecture.7.xml @@ -48,18 +48,18 @@ <li> <p> - Zero or more <dfn>gateways</dfn>. A gateway extends a tunnel-based - logical network into a physical network by bidirectionally forwarding - packets between tunnels and a physical Ethernet port. This allows - non-virtualized machines to participate in logical networks. A gateway - may be a physical host, a virtual machine, or an ASIC-based hardware - switch that supports the <code>vtep</code>(5) schema. (Support for the - latter will come later in OVN implementation.) + Zero or more <dfn>gateways</dfn>. A gateway extends a tunnel-based + logical network into a physical network by bidirectionally forwarding + packets between tunnels and a physical Ethernet port. This allows + non-virtualized machines to participate in logical networks. A gateway + may be a physical host, a virtual machine, or an ASIC-based hardware + switch that supports the <code>vtep</code>(5) schema. (Support for the + latter will come later in OVN implementation.) </p> <p> - Hypervisors and gateways are together called <dfn>transport node</dfn> - or <dfn>chassis</dfn>. + Hypervisors and gateways are together called <dfn>transport node</dfn> + or <dfn>chassis</dfn>. </p> </li> </ul> @@ -76,34 +76,34 @@ <li> <p> - The <dfn>OVN/CMS Plugin</dfn> is the component of the CMS that - interfaces to OVN. In OpenStack, this is a Neutron plugin. - The plugin's main purpose is to translate the CMS's notion of logical - network configuration, stored in the CMS's configuration database in a - CMS-specific format, into an intermediate representation understood by - OVN. + The <dfn>OVN/CMS Plugin</dfn> is the component of the CMS that + interfaces to OVN. In OpenStack, this is a Neutron plugin. + The plugin's main purpose is to translate the CMS's notion of logical + network configuration, stored in the CMS's configuration database in a + CMS-specific format, into an intermediate representation understood by + OVN. </p> <p> - This component is necessarily CMS-specific, so a new plugin needs to be - developed for each CMS that is integrated with OVN. All of the - components below this one in the diagram are CMS-independent. + This component is necessarily CMS-specific, so a new plugin needs to be + developed for each CMS that is integrated with OVN. All of the + components below this one in the diagram are CMS-independent. </p> </li> <li> <p> - The <dfn>OVN Northbound Database</dfn> receives the intermediate - representation of logical network configuration passed down by the - OVN/CMS Plugin. The database schema is meant to be ``impedance - matched'' with the concepts used in a CMS, so that it directly supports - notions of logical switches, routers, ACLs, and so on. See - <code>ovs-nb</code>(5) for details. + The <dfn>OVN Northbound Database</dfn> receives the intermediate + representation of logical network configuration passed down by the + OVN/CMS Plugin. The database schema is meant to be ``impedance + matched'' with the concepts used in a CMS, so that it directly supports + notions of logical switches, routers, ACLs, and so on. See + <code>ovs-nb</code>(5) for details. </p> <p> - The OVN Northbound Database has only two clients: the OVN/CMS Plugin - above it and <code>ovn-northd</code> below it. + The OVN Northbound Database has only two clients: the OVN/CMS Plugin + above it and <code>ovn-northd</code> below it. </p> </li> @@ -123,14 +123,14 @@ </p> <p> - The OVN Southbound Database contains three kinds of data: <dfn>Physical - Network</dfn> (PN) tables that specify how to reach hypervisor and - other nodes, <dfn>Logical Network</dfn> (LN) tables that describe the - logical network in terms of ``logical datapath flows,'' and - <dfn>Binding</dfn> tables that link logical network components' - locations to the physical network. The hypervisors populate the PN and - Binding tables, whereas <code>ovn-northd</code>(8) populates the LN - tables. + The OVN Southbound Database contains three kinds of data: <dfn>Physical + Network</dfn> (PN) tables that specify how to reach hypervisor and + other nodes, <dfn>Logical Network</dfn> (LN) tables that describe the + logical network in terms of ``logical datapath flows,'' and + <dfn>Binding</dfn> tables that link logical network components' + locations to the physical network. The hypervisors populate the PN and + Binding tables, whereas <code>ovn-northd</code>(8) populates the LN + tables. </p> <p> diff --git a/ovn/ovn-nb.xml b/ovn/ovn-nb.xml index 2d0632e..bd941b4 100644 --- a/ovn/ovn-nb.xml +++ b/ovn/ovn-nb.xml @@ -200,23 +200,23 @@ <p>The action to take when the ACL rule matches:</p> <ul> - <li> - <code>allow</code>: Forward the packet. - </li> - - <li> - <code>allow-related</code>: Forward the packet and related traffic - (e.g. inbound replies to an outbound connection). - </li> - - <li> - <code>drop</code>: Silently drop the packet. - </li> - - <li> - <code>reject</code>: Drop the packet, replying with a RST for TCP or - ICMP unreachable message for other IP-based protocols. - </li> + <li> + <code>allow</code>: Forward the packet. + </li> + + <li> + <code>allow-related</code>: Forward the packet and related traffic + (e.g. inbound replies to an outbound connection). + </li> + + <li> + <code>drop</code>: Silently drop the packet. + </li> + + <li> + <code>reject</code>: Drop the packet, replying with a RST for TCP or + ICMP unreachable message for other IP-based protocols. + </li> </ul> </column> diff --git a/ovn/ovn-sb.xml b/ovn/ovn-sb.xml index e305622..c1df1f9 100644 --- a/ovn/ovn-sb.xml +++ b/ovn/ovn-sb.xml @@ -246,13 +246,13 @@ </p> <p> - The most important components of match expression are - <dfn>comparisons</dfn> between <dfn>symbols</dfn> and - <dfn>constants</dfn>, e.g. <code>ip4.dst == 192.168.0.1</code>, - <code>ip.proto == 6</code>, <code>arp.op == 1</code>, <code>eth.type == - 0x800</code>. The logical AND operator <code>&&</code> and - logical OR operator <code>||</code> can combine comparisons into a - larger expression. + The most important components of match expression are + <dfn>comparisons</dfn> between <dfn>symbols</dfn> and + <dfn>constants</dfn>, e.g. <code>ip4.dst == 192.168.0.1</code>, + <code>ip.proto == 6</code>, <code>arp.op == 1</code>, <code>eth.type == + 0x800</code>. The logical AND operator <code>&&</code> and + logical OR operator <code>||</code> can combine comparisons into a + larger expression. </p> <p> @@ -266,167 +266,167 @@ <p><em>Symbols</em></p> <p> - <em>Type</em>. Symbols have <dfn>integer</dfn> or <dfn>string</dfn> - type. Integer symbols have a <dfn>width</dfn> in bits. + <em>Type</em>. Symbols have <dfn>integer</dfn> or <dfn>string</dfn> + type. Integer symbols have a <dfn>width</dfn> in bits. </p> <p> - <em>Kinds</em>. There are three kinds of symbols: + <em>Kinds</em>. There are three kinds of symbols: </p> <ul> - <li> - <p> - <dfn>Fields</dfn>. A field symbol represents a packet header or - metadata field. For example, a field - named <code>vlan.tci</code> might represent the VLAN TCI field in a - packet. - </p> - - <p> - A field symbol can have integer or string type. Integer fields can - be nominal or ordinal (see <em>Level of Measurement</em>, - below). - </p> - </li> - - <li> - <p> - <dfn>Subfields</dfn>. A subfield represents a subset of bits from - a larger field. For example, a field <code>vlan.vid</code> might - be defined as an alias for <code>vlan.tci[0..11]</code>. Subfields - are provided for syntactic convenience, because it is always - possible to instead refer to a subset of bits from a field - directly. - </p> - - <p> - Only ordinal fields (see <em>Level of Measurement</em>, - below) may have subfields. Subfields are always ordinal. - </p> - </li> - - <li> - <p> - <dfn>Predicates</dfn>. A predicate is shorthand for a Boolean - expression. Predicates may be used much like 1-bit fields. For - example, <code>ip4</code> might expand to <code>eth.type == - 0x800</code>. Predicates are provided for syntactic convenience, - because it is always possible to instead specify the underlying - expression directly. - </p> - - <p> - A predicate whose expansion refers to any nominal field or - predicate (see <em>Level of Measurement</em>, below) is nominal; - other predicates have Boolean level of measurement. - </p> - </li> + <li> + <p> + <dfn>Fields</dfn>. A field symbol represents a packet header or + metadata field. For example, a field + named <code>vlan.tci</code> might represent the VLAN TCI field in a + packet. + </p> + + <p> + A field symbol can have integer or string type. Integer fields can + be nominal or ordinal (see <em>Level of Measurement</em>, + below). + </p> + </li> + + <li> + <p> + <dfn>Subfields</dfn>. A subfield represents a subset of bits from + a larger field. For example, a field <code>vlan.vid</code> might + be defined as an alias for <code>vlan.tci[0..11]</code>. Subfields + are provided for syntactic convenience, because it is always + possible to instead refer to a subset of bits from a field + directly. + </p> + + <p> + Only ordinal fields (see <em>Level of Measurement</em>, + below) may have subfields. Subfields are always ordinal. + </p> + </li> + + <li> + <p> + <dfn>Predicates</dfn>. A predicate is shorthand for a Boolean + expression. Predicates may be used much like 1-bit fields. For + example, <code>ip4</code> might expand to <code>eth.type == + 0x800</code>. Predicates are provided for syntactic convenience, + because it is always possible to instead specify the underlying + expression directly. + </p> + + <p> + A predicate whose expansion refers to any nominal field or + predicate (see <em>Level of Measurement</em>, below) is nominal; + other predicates have Boolean level of measurement. + </p> + </li> </ul> <p> - <em>Level of Measurement</em>. See - http://en.wikipedia.org/wiki/Level_of_measurement for the statistical - concept on which this classification is based. There are three - levels: + <em>Level of Measurement</em>. See + http://en.wikipedia.org/wiki/Level_of_measurement for the statistical + concept on which this classification is based. There are three + levels: </p> <ul> - <li> - <p> - <dfn>Ordinal</dfn>. In statistics, ordinal values can be ordered - on a scale. OVN considers a field (or subfield) to be ordinal if - its bits can be examined individually. This is true for the - OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable.'' - </p> - - <p> - Any use of a nominal field may specify a single bit or a range of - bits, e.g. <code>vlan.tci[13..15]</code> refers to the PCP field - within the VLAN TCI, and <code>eth.dst[40]</code> refers to the - multicast bit in the Ethernet destination address. - </p> - - <p> - OVN supports all the usual arithmetic relations (<code>==</code>, - <code>!=</code>, <code><</code>, <code><=</code>, - <code>></code>, and <code>>=</code>) on ordinal fields and - their subfields, because OVN can implement these in OpenFlow and - Open vSwitch as collections of bitwise tests. - </p> - </li> - - <li> - <p> - <dfn>Nominal</dfn>. In statistics, nominal values cannot be - usefully compared except for equality. This is true of OpenFlow - port numbers, Ethernet types, and IP protocols are examples: all of - these are just identifiers assigned arbitrarily with no deeper - meaning. In OpenFlow and Open vSwitch, bits in these fields - generally aren't individually addressable. - </p> - - <p> - OVN only supports arithmetic tests for equality on nominal fields, - because OpenFlow and Open vSwitch provide no way for a flow to - efficiently implement other comparisons on them. (A test for - inequality can be sort of built out of two flows with different - priorities, but OVN matching expressions always generate flows with - a single priority.) - </p> - - <p> - String fields are always nominal. - </p> - </li> - - <li> - <p> - <dfn>Boolean</dfn>. A nominal field that has only two values, 0 - and 1, is somewhat exceptional, since it is easy to support both - equality and inequality tests on such a field: either one can be - implemented as a test for 0 or 1. - </p> - - <p> - Only predicates (see above) have a Boolean level of measurement. - </p> - - <p> - This isn't a standard level of measurement. - </p> - </li> + <li> + <p> + <dfn>Ordinal</dfn>. In statistics, ordinal values can be ordered + on a scale. OVN considers a field (or subfield) to be ordinal if + its bits can be examined individually. This is true for the + OpenFlow fields that OpenFlow or Open vSwitch makes ``maskable.'' + </p> + + <p> + Any use of a nominal field may specify a single bit or a range of + bits, e.g. <code>vlan.tci[13..15]</code> refers to the PCP field + within the VLAN TCI, and <code>eth.dst[40]</code> refers to the + multicast bit in the Ethernet destination address. + </p> + + <p> + OVN supports all the usual arithmetic relations (<code>==</code>, + <code>!=</code>, <code><</code>, <code><=</code>, + <code>></code>, and <code>>=</code>) on ordinal fields and + their subfields, because OVN can implement these in OpenFlow and + Open vSwitch as collections of bitwise tests. + </p> + </li> + + <li> + <p> + <dfn>Nominal</dfn>. In statistics, nominal values cannot be + usefully compared except for equality. This is true of OpenFlow + port numbers, Ethernet types, and IP protocols are examples: all of + these are just identifiers assigned arbitrarily with no deeper + meaning. In OpenFlow and Open vSwitch, bits in these fields + generally aren't individually addressable. + </p> + + <p> + OVN only supports arithmetic tests for equality on nominal fields, + because OpenFlow and Open vSwitch provide no way for a flow to + efficiently implement other comparisons on them. (A test for + inequality can be sort of built out of two flows with different + priorities, but OVN matching expressions always generate flows with + a single priority.) + </p> + + <p> + String fields are always nominal. + </p> + </li> + + <li> + <p> + <dfn>Boolean</dfn>. A nominal field that has only two values, 0 + and 1, is somewhat exceptional, since it is easy to support both + equality and inequality tests on such a field: either one can be + implemented as a test for 0 or 1. + </p> + + <p> + Only predicates (see above) have a Boolean level of measurement. + </p> + + <p> + This isn't a standard level of measurement. + </p> + </li> </ul> <p> - <em>Prerequisites</em>. Any symbol can have prerequisites, which are - additional condition implied by the use of the symbol. For example, - For example, <code>icmp4.type</code> symbol might have prerequisite - <code>icmp4</code>, which would cause an expression <code>icmp4.type == - 0</code> to be interpreted as <code>icmp4.type == 0 && - icmp4</code>, which would in turn expand to <code>icmp4.type == 0 - && eth.type == 0x800 && ip4.proto == 1</code> (assuming - <code>icmp4</code> is a predicate defined as suggested under - <em>Types</em> above). + <em>Prerequisites</em>. Any symbol can have prerequisites, which are + additional condition implied by the use of the symbol. For example, + For example, <code>icmp4.type</code> symbol might have prerequisite + <code>icmp4</code>, which would cause an expression <code>icmp4.type == + 0</code> to be interpreted as <code>icmp4.type == 0 && + icmp4</code>, which would in turn expand to <code>icmp4.type == 0 + && eth.type == 0x800 && ip4.proto == 1</code> (assuming + <code>icmp4</code> is a predicate defined as suggested under + <em>Types</em> above). </p> <p><em>Relational operators</em></p> <p> - All of the standard relational operators <code>==</code>, - <code>!=</code>, <code><</code>, <code><=</code>, - <code>></code>, and <code>>=</code> are supported. Nominal - fields support only <code>==</code> and <code>!=</code>, and only in a - positive sense when outer <code>!</code> are taken into account, - e.g. given string field <code>inport</code>, <code>inport == - "eth0"</code> and <code>!(inport != "eth0")</code> are acceptable, but - not <code>inport != "eth0"</code>. + All of the standard relational operators <code>==</code>, + <code>!=</code>, <code><</code>, <code><=</code>, + <code>></code>, and <code>>=</code> are supported. Nominal + fields support only <code>==</code> and <code>!=</code>, and only in a + positive sense when outer <code>!</code> are taken into account, + e.g. given string field <code>inport</code>, <code>inport == + "eth0"</code> and <code>!(inport != "eth0")</code> are acceptable, but + not <code>inport != "eth0"</code>. </p> <p> - The implementation of <code>==</code> (or <code>!=</code> when it is - negated), is more efficient than that of the other relational - operators. + The implementation of <code>==</code> (or <code>!=</code> when it is + negated), is more efficient than that of the other relational + operators. </p> <p><em>Constants</em></p> @@ -467,38 +467,38 @@ <p><em>Miscellaneous</em></p> <p> - Comparisons may name the symbol or the constant first, - e.g. <code>tcp.src == 80</code> and <code>80 == tcp.src</code> are both - acceptable. + Comparisons may name the symbol or the constant first, + e.g. <code>tcp.src == 80</code> and <code>80 == tcp.src</code> are both + acceptable. </p> <p> - Tests for a range may be expressed using a syntax like <code>1024 <= - tcp.src <= 49151</code>, which is equivalent to <code>1024 <= - tcp.src && tcp.src <= 49151</code>. + Tests for a range may be expressed using a syntax like <code>1024 <= + tcp.src <= 49151</code>, which is equivalent to <code>1024 <= + tcp.src && tcp.src <= 49151</code>. </p> <p> - For a one-bit field or predicate, a mention of its name is equivalent - to <code><var>symobl</var> == 1</code>, e.g. <code>vlan.present</code> - is equivalent to <code>vlan.present == 1</code>. The same is true for - one-bit subfields, e.g. <code>vlan.tci[12]</code>. There is no - technical limitation to implementing the same for ordinal fields of all - widths, but the implementation is expensive enough that the syntax - parser requires writing an explicit comparison against zero to make - mistakes less likely, e.g. in <code>tcp.src != 0</code> the comparison - against 0 is required. + For a one-bit field or predicate, a mention of its name is equivalent + to <code><var>symobl</var> == 1</code>, e.g. <code>vlan.present</code> + is equivalent to <code>vlan.present == 1</code>. The same is true for + one-bit subfields, e.g. <code>vlan.tci[12]</code>. There is no + technical limitation to implementing the same for ordinal fields of all + widths, but the implementation is expensive enough that the syntax + parser requires writing an explicit comparison against zero to make + mistakes less likely, e.g. in <code>tcp.src != 0</code> the comparison + against 0 is required. </p> <p> - <em>Operator precedence</em> is as shown below, from highest to lowest. - There are two exceptions where parentheses are required even though the - table would suggest that they are not: <code>&&</code> and - <code>||</code> require parentheses when used together, and - <code>!</code> requires parentheses when applied to a relational - expression. Thus, in <code>(eth.type == 0x800 || eth.type == 0x86dd) - && ip.proto == 6</code> or <code>!(arp.op == 1)</code>, the - parentheses are mandatory. + <em>Operator precedence</em> is as shown below, from highest to lowest. + There are two exceptions where parentheses are required even though the + table would suggest that they are not: <code>&&</code> and + <code>||</code> require parentheses when used together, and + <code>!</code> requires parentheses when applied to a relational + expression. Thus, in <code>(eth.type == 0x800 || eth.type == 0x86dd) + && ip.proto == 6</code> or <code>!(arp.op == 1)</code>, the + parentheses are mandatory. </p> <ul> @@ -583,8 +583,8 @@ <dt><code>icmp_reply { <var>action</var>, </code>...<code> }</code></dt> <dd>generate ICMP reply from packet, execute <var>action</var>s</dd> - <dt><code>arp { <var>action</var>, </code>...<code> }</code></dt> - <dd>generate ARP from packet, execute <var>action</var>s</dd> + <dt><code>arp { <var>action</var>, </code>...<code> }</code></dt> + <dd>generate ARP from packet, execute <var>action</var>s</dd> </dl> <p> -- 2.1.0 _______________________________________________ dev mailing list [email protected] http://openvswitch.org/mailman/listinfo/dev
