[ovs-dev] [PATCH] vswitch.xml: Untabify and reindent.

Justin Pettit jpettit at nicira.com
Tue Oct 13 23:16:41 UTC 2015


Thanks!

Acked-by: Justin Pettit <jpettit at nicira.com>

--Justin


> On Oct 13, 2015, at 4:15 PM, Ben Pfaff <blp at nicira.com> wrote:
> 
> This is a large patch but it is entirely whitespace changes.
> 
> Suggested-by: Justin Pettit <jpettit at nicira.com>
> Signed-off-by: Ben Pfaff <blp at nicira.com>
> ---
> vswitchd/vswitch.xml | 684 ++++++++++++++++++++++++++-------------------------
> 1 file changed, 346 insertions(+), 338 deletions(-)
> 
> diff --git a/vswitchd/vswitch.xml b/vswitchd/vswitch.xml
> index 0ab4a9a..c94f42d 100644
> --- a/vswitchd/vswitch.xml
> +++ b/vswitchd/vswitch.xml
> @@ -530,7 +530,7 @@
>       </column>
> 
>       <column name="auto_attach">
> -          Auto Attach configuration.
> +        Auto Attach configuration.
>       </column>
>     </group>
> 
> @@ -685,16 +685,16 @@
>       </column>
> 
>       <column name="protocols">
> -	<p>
> -	  List of OpenFlow protocols that may be used when negotiating
> -	  a connection with a controller.  OpenFlow 1.0, 1.1, 1.2, and
> -	  1.3 are enabled by default if this column is empty.
> -	</p>
> +        <p>
> +          List of OpenFlow protocols that may be used when negotiating
> +          a connection with a controller.  OpenFlow 1.0, 1.1, 1.2, and
> +          1.3 are enabled by default if this column is empty.
> +        </p>
> 
> -	<p>
> -	  OpenFlow 1.4 is not enabled by default because its implementation is
> -	  missing features.
> -	</p>
> +        <p>
> +          OpenFlow 1.4 is not enabled by default because its implementation is
> +          missing features.
> +        </p>
> 
>         <p>
>           OpenFlow 1.5 has the same risks as OpenFlow 1.4, but it is even more
> @@ -982,45 +982,45 @@
>       <column name="other_config" key="forward-bpdu"
>               type='{"type": "boolean"}'>
> 
> -	<p>
> +        <p>
>           Controls forwarding of BPDUs and other network control frames when
>           NORMAL action is invoked.  When this option is <code>false</code> or
>           unset, frames with reserved Ethernet addresses (see table below) will
>           not be forwarded.  When this option is <code>true</code>, such frames
>           will not be treated specially.
> -	</p>
> -
> -	<p>
> -	  The above general rule has the following exceptions:
> -	</p>
> -
> -	<ul>
> -	  <li>
> -	    If STP is enabled on the bridge (see the <ref column="stp_enable"
> -	    table="Bridge"/> column in the <ref table="Bridge"/> table), the
> -	    bridge processes all received STP packets and never passes them to
> -	    OpenFlow or forwards them.  This is true even if STP is disabled on
> -	    an individual port.
> -	  </li>
> -
> -	  <li>
> -	    If LLDP is enabled on an interface (see the <ref column="lldp"
> -	    table="Interface"/> column in the <ref table="Interface"/> table),
> -	    the interface processes received LLDP packets and never passes them
> -	    to OpenFlow or forwards them.
> -	  </li>
> -	</ul>
> -
> -	<p>
> -	  Set this option to <code>true</code> if the Open vSwitch bridge
> -	  connects different Ethernet networks and is not configured to
> -	  participate in STP.
> -	</p>
> -
> -        <p>
> -	  This option affects packets with the following destination MAC
> -	  addresses:
> -	</p>
> +        </p>
> +
> +        <p>
> +          The above general rule has the following exceptions:
> +        </p>
> +
> +        <ul>
> +          <li>
> +            If STP is enabled on the bridge (see the <ref column="stp_enable"
> +            table="Bridge"/> column in the <ref table="Bridge"/> table), the
> +            bridge processes all received STP packets and never passes them to
> +            OpenFlow or forwards them.  This is true even if STP is disabled on
> +            an individual port.
> +          </li>
> +
> +          <li>
> +            If LLDP is enabled on an interface (see the <ref column="lldp"
> +            table="Interface"/> column in the <ref table="Interface"/> table),
> +            the interface processes received LLDP packets and never passes them
> +            to OpenFlow or forwards them.
> +          </li>
> +        </ul>
> +
> +        <p>
> +          Set this option to <code>true</code> if the Open vSwitch bridge
> +          connects different Ethernet networks and is not configured to
> +          participate in STP.
> +        </p>
> +
> +        <p>
> +          This option affects packets with the following destination MAC
> +          addresses:
> +        </p>
> 
>         <dl>
>           <dt><code>01:80:c2:00:00:00</code></dt>
> @@ -1036,8 +1036,8 @@
>           <dd>Extreme Discovery Protocol (EDP).</dd>
> 
>           <dt>
> -	    <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code>
> -	  </dt>
> +            <code>00:e0:2b:00:00:04</code> and <code>00:e0:2b:00:00:06</code>
> +          </dt>
>           <dd>Ethernet Automatic Protection Switching (EAPS).</dd>
> 
>           <dt><code>01:00:0c:cc:cc:cc</code></dt>
> @@ -1099,8 +1099,8 @@
>       <column name="external_ids"/>
>     </group>
>   </table>
> - 
> - <table name="Port" table="Port or bond configuration.">
> +  
> +  <table name="Port" table="Port or bond configuration.">
>     <p>A port within a <ref table="Bridge"/>.</p>
>     <p>Most commonly, a port has exactly one ``interface,'' pointed to by its
>     <ref column="interfaces"/> column.  Such a port logically
> @@ -1382,7 +1382,7 @@
>         </column>
> 
>         <column name="other_config" key="lacp-time"
> -          type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'>
> +                type='{"type": "string", "enum": ["set", ["fast", "slow"]]}'>
>           <p>
>             The LACP timing which should be used on this <ref table="Port"/>.
>             By default <code>slow</code> is used.  When configured to be
> @@ -1394,7 +1394,7 @@
>         </column>
> 
>         <column name="other_config" key="lacp-fallback-ab"
> -          type='{"type": "boolean"}'>
> +                type='{"type": "boolean"}'>
>           <p>
>             Determines the behavior of openvswitch bond in LACP mode. If
>             the partner switch does not support LACP, setting this option
> @@ -1753,57 +1753,57 @@
>       </column>
> 
>       <group title="OpenFlow Port Number">
> -	<p>
> -	  When a client adds a new interface, Open vSwitch chooses an OpenFlow
> -	  port number for the new port.  If the client that adds the port fills
> -	  in <ref column="ofport_request"/>, then Open vSwitch tries to use its
> -	  value as the OpenFlow port number.  Otherwise, or if the requested
> -	  port number is already in use or cannot be used for another reason,
> -	  Open vSwitch automatically assigns a free port number.  Regardless of
> -	  how the port number was obtained, Open vSwitch then reports in <ref
> -	  column="ofport"/> the port number actually assigned.
> -	</p>
> -
> -	<p>
> -	  Open vSwitch limits the port numbers that it automatically assigns to
> -	  the range 1 through 32,767, inclusive.  Controllers therefore have
> -	  free use of ports 32,768 and up.
> -	</p>
> -
> -	<column name="ofport">
> -	  <p>
> -	    OpenFlow port number for this interface.  Open vSwitch sets this
> -	    column's value, so other clients should treat it as read-only.
> -	  </p>
> -	  <p>
> -	    The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534.
> -	    The other valid port numbers are in the range 1 to 65,279,
> -	    inclusive.  Value -1 indicates an error adding the interface.
> -	  </p>
> -	</column>
> -
> -	<column name="ofport_request"
> -		type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'>
> -	  <p>
> -	    Requested OpenFlow port number for this interface.
> -	  </p>
> -
> -	  <p>
> -	    A client should ideally set this column's value in the same
> -	    database transaction that it uses to create the interface.  Open
> -	    vSwitch version 2.1 and later will honor a later request for a
> -	    specific port number, althuogh it might confuse some controllers:
> -	    OpenFlow does not have a way to announce a port number change, so
> -	    Open vSwitch represents it over OpenFlow as a port deletion
> -	    followed immediately by a port addition.
> -	  </p>
> -
> -	  <p>
> -	    If <ref column="ofport_request"/> is set or changed to some other
> -	    port's automatically assigned port number, Open vSwitch chooses a
> -	    new port number for the latter port.
> -	  </p>
> -	</column>
> +        <p>
> +          When a client adds a new interface, Open vSwitch chooses an OpenFlow
> +          port number for the new port.  If the client that adds the port fills
> +          in <ref column="ofport_request"/>, then Open vSwitch tries to use its
> +          value as the OpenFlow port number.  Otherwise, or if the requested
> +          port number is already in use or cannot be used for another reason,
> +          Open vSwitch automatically assigns a free port number.  Regardless of
> +          how the port number was obtained, Open vSwitch then reports in <ref
> +          column="ofport"/> the port number actually assigned.
> +        </p>
> +
> +        <p>
> +          Open vSwitch limits the port numbers that it automatically assigns to
> +          the range 1 through 32,767, inclusive.  Controllers therefore have
> +          free use of ports 32,768 and up.
> +        </p>
> +
> +        <column name="ofport">
> +          <p>
> +            OpenFlow port number for this interface.  Open vSwitch sets this
> +            column's value, so other clients should treat it as read-only.
> +          </p>
> +          <p>
> +            The OpenFlow ``local'' port (<code>OFPP_LOCAL</code>) is 65,534.
> +            The other valid port numbers are in the range 1 to 65,279,
> +            inclusive.  Value -1 indicates an error adding the interface.
> +          </p>
> +        </column>
> +
> +        <column name="ofport_request"
> +                type='{"type": "integer", "minInteger": 1, "maxInteger": 65279}'>
> +          <p>
> +            Requested OpenFlow port number for this interface.
> +          </p>
> +
> +          <p>
> +            A client should ideally set this column's value in the same
> +            database transaction that it uses to create the interface.  Open
> +            vSwitch version 2.1 and later will honor a later request for a
> +            specific port number, althuogh it might confuse some controllers:
> +            OpenFlow does not have a way to announce a port number change, so
> +            Open vSwitch represents it over OpenFlow as a port deletion
> +            followed immediately by a port addition.
> +          </p>
> +
> +          <p>
> +            If <ref column="ofport_request"/> is set or changed to some other
> +            port's automatically assigned port number, Open vSwitch chooses a
> +            new port number for the latter port.
> +          </p>
> +        </column>
>       </group>
>     </group>
> 
> @@ -1858,15 +1858,15 @@
> 
>           <dt><code>vxlan</code></dt>
>           <dd>
> -	    <p>
> -	      An Ethernet tunnel over the UDP-based VXLAN protocol described in
> -	      RFC 7348.
> -	    </p>
> -	    <p>
> -	      Open vSwitch uses UDP destination port 4789.  The source port used for
> -	      VXLAN traffic varies on a per-flow basis and is in the ephemeral port
> -	      range.
> -	    </p>
> +            <p>
> +              An Ethernet tunnel over the UDP-based VXLAN protocol described in
> +              RFC 7348.
> +            </p>
> +            <p>
> +              Open vSwitch uses UDP destination port 4789.  The source port used for
> +              VXLAN traffic varies on a per-flow basis and is in the ephemeral port
> +              range.
> +            </p>
>           </dd>
> 
>           <dt><code>lisp</code></dt>
> @@ -1887,21 +1887,21 @@
> 
>           <dt><code>stt</code></dt>
>           <dd>
> -             The Stateless TCP Tunnel (STT) is particularly useful when tunnel
> -             endpoints are in end-systems, as it utilizes the capabilities of
> -             standard network interface cards to improve performance.  STT utilizes
> -             a TCP-like header inside the IP header. It is stateless, i.e., there is
> -             no TCP connection state of any kind associated with the tunnel.  The
> -             TCP-like header is used to leverage the capabilities of existing
> -             network interface cards, but should not be interpreted as implying
> -             any sort of connection state between endpoints.
> -             Since the STT protocol does not engage in the usual TCP 3-way handshake,
> -             so it will have difficulty traversing stateful firewalls.
> -             The protocol is documented at
> -             http://www.ietf.org/archive/id/draft-davie-stt-06.txt
> -
> -             All traffic uses a default destination port of 7471. STT is only
> -             available in kernel datapath on kernel 3.5 or newer.
> +            The Stateless TCP Tunnel (STT) is particularly useful when tunnel
> +            endpoints are in end-systems, as it utilizes the capabilities of
> +            standard network interface cards to improve performance.  STT utilizes
> +            a TCP-like header inside the IP header. It is stateless, i.e., there is
> +            no TCP connection state of any kind associated with the tunnel.  The
> +            TCP-like header is used to leverage the capabilities of existing
> +            network interface cards, but should not be interpreted as implying
> +            any sort of connection state between endpoints.
> +            Since the STT protocol does not engage in the usual TCP 3-way handshake,
> +            so it will have difficulty traversing stateful firewalls.
> +            The protocol is documented at
> +            http://www.ietf.org/archive/id/draft-davie-stt-06.txt
> +
> +            All traffic uses a default destination port of 7471. STT is only
> +            available in kernel datapath on kernel 3.5 or newer.
>           </dd>
> 
>           <dt><code>patch</code></dt>
> @@ -1911,7 +1911,7 @@
> 
>           <dt><code>null</code></dt>
>           <dd>An ignored interface. Deprecated and slated for removal in
> -              February 2013.</dd>
> +          February 2013.</dd>
>         </dl>
>       </column>
>     </group>
> @@ -1955,9 +1955,9 @@
>         </ul>
> 
>         <p>
> -         The remote tunnel endpoint for any packet received from a tunnel
> -         is available in the <code>tun_src</code> field for matching in the
> -         flow table.
> +          The remote tunnel endpoint for any packet received from a tunnel
> +          is available in the <code>tun_src</code> field for matching in the
> +          flow table.
>         </p>
>       </column>
> 
> @@ -2079,23 +2079,23 @@
> 
>       <group title="Tunnel Options: vxlan only">
> 
> -      <column name="options" key="exts">
> -        <p>Optional.  Comma separated list of optional VXLAN extensions to
> -           enable. The following extensions are supported:</p>
> +        <column name="options" key="exts">
> +          <p>Optional.  Comma separated list of optional VXLAN extensions to
> +          enable. The following extensions are supported:</p>
> 
> -        <ul>
> -          <li>
> -            <code>gbp</code>: VXLAN-GBP allows to transport the group policy
> -            context of a packet across the VXLAN tunnel to other network
> -            peers. See the field description of <code>tun_gbp_id</code> and
> -            <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional
> -            information.
> -            (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>)
> -          </li>
> -        </ul>
> -      </column>
> +          <ul>
> +            <li>
> +              <code>gbp</code>: VXLAN-GBP allows to transport the group policy
> +              context of a packet across the VXLAN tunnel to other network
> +              peers. See the field description of <code>tun_gbp_id</code> and
> +              <code>tun_gbp_flags</code> in ovs-ofctl(8) for additional
> +              information.
> +              (<code>https://tools.ietf.org/html/draft-smith-vxlan-group-policy</code>)
> +            </li>
> +          </ul>
> +        </column>
> 
> -	  </group>
> +      </group>
> 
>       <group title="Tunnel Options: gre, ipsec_gre, geneve, and vxlan">
>         <p>
> @@ -2109,7 +2109,7 @@
>             checksums on outgoing packets.  Default is disabled, set to
>             <code>true</code> to enable.  Checksums present on incoming
>             packets will be validated regardless of this setting.
> -	  </p>
> +          </p>
> 
>           <p>
>             When using the upstream Linux kernel module, computation of
> @@ -2122,9 +2122,9 @@
>           </p>
> 
>           <p>
> -	    This option is supported for <code>ipsec_gre</code>, but not useful
> -	    because GRE checksums are weaker than, and redundant with, IPsec
> -	    payload authentication.
> +            This option is supported for <code>ipsec_gre</code>, but not useful
> +            because GRE checksums are weaker than, and redundant with, IPsec
> +            payload authentication.
>           </p>
>         </column>
>       </group>
> @@ -2419,70 +2419,70 @@
> 
>     <group title="Bidirectional Forwarding Detection (BFD)">
>       <p>
> -	BFD, defined in RFC 5880 and RFC 5881, allows point-to-point
> -	detection of connectivity failures by occasional transmission of
> -	BFD control messages.  Open vSwitch implements BFD to serve
> -	as a more popular and standards compliant alternative to CFM.
> +        BFD, defined in RFC 5880 and RFC 5881, allows point-to-point
> +        detection of connectivity failures by occasional transmission of
> +        BFD control messages.  Open vSwitch implements BFD to serve
> +        as a more popular and standards compliant alternative to CFM.
>       </p>
> 
>       <p>
> -	BFD operates by regularly transmitting BFD control messages at a rate
> -	negotiated independently in each direction.  Each endpoint specifies
> -	the rate at which it expects to receive control messages, and the rate
> -	at which it is willing to transmit them.  Open vSwitch uses a detection
> -	multiplier of three, meaning that an endpoint signals a connectivity
> -	fault if three consecutive BFD control messages fail to arrive.  In the
> -	case of a unidirectional connectivity issue, the system not receiving
> -	BFD control messages signals the problem to its peer in the messages it
> -	transmits.
> +        BFD operates by regularly transmitting BFD control messages at a rate
> +        negotiated independently in each direction.  Each endpoint specifies
> +        the rate at which it expects to receive control messages, and the rate
> +        at which it is willing to transmit them.  Open vSwitch uses a detection
> +        multiplier of three, meaning that an endpoint signals a connectivity
> +        fault if three consecutive BFD control messages fail to arrive.  In the
> +        case of a unidirectional connectivity issue, the system not receiving
> +        BFD control messages signals the problem to its peer in the messages it
> +        transmits.
>       </p>
> 
>       <p>
> -	The Open vSwitch implementation of BFD aims to comply faithfully
> -	with RFC 5880 requirements.  Open vSwitch does not implement the
> -	optional Authentication or ``Echo Mode'' features.
> +        The Open vSwitch implementation of BFD aims to comply faithfully
> +        with RFC 5880 requirements.  Open vSwitch does not implement the
> +        optional Authentication or ``Echo Mode'' features.
>       </p>
> 
>       <group title="BFD Configuration">
> -	<p>
> -	  A controller sets up key-value pairs in the <ref column="bfd"/>
> -	  column to enable and configure BFD.
> -	</p>
> +        <p>
> +          A controller sets up key-value pairs in the <ref column="bfd"/>
> +          column to enable and configure BFD.
> +        </p>
> 
> -	<column name="bfd" key="enable" type='{"type": "boolean"}'>
> +        <column name="bfd" key="enable" type='{"type": "boolean"}'>
>           True to enable BFD on this <ref table="Interface"/>.  If not
>           specified, BFD will not be enabled by default.
> -	</column>
> +        </column>
> 
> -	<column name="bfd" key="min_rx"
> -		type='{"type": "integer", "minInteger": 1}'>
> +        <column name="bfd" key="min_rx"
> +                type='{"type": "integer", "minInteger": 1}'>
>           The shortest interval, in milliseconds, at which this BFD session
>           offers to receive BFD control messages.  The remote endpoint may
>           choose to send messages at a slower rate.  Defaults to
>           <code>1000</code>.
> -	</column>
> +        </column>
> 
> -	<column name="bfd" key="min_tx"
> -		type='{"type": "integer", "minInteger": 1}'>
> +        <column name="bfd" key="min_tx"
> +                type='{"type": "integer", "minInteger": 1}'>
>           The shortest interval, in milliseconds, at which this BFD session is
>           willing to transmit BFD control messages.  Messages will actually be
>           transmitted at a slower rate if the remote endpoint is not willing to
>           receive as quickly as specified.  Defaults to <code>100</code>.
> -	</column>
> -
> -	<column name="bfd" key="decay_min_rx" type='{"type": "integer"}'>
> -	  An alternate receive interval, in milliseconds, that must be greater
> -	  than or equal to <ref column="bfd" key="min_rx"/>.  The
> -	  implementation switches from <ref column="bfd" key="min_rx"/> to <ref
> -	  column="bfd" key="decay_min_rx"/> when there is no obvious incoming
> -	  data traffic at the interface, to reduce the CPU and bandwidth cost
> -	  of monitoring an idle interface.  This feature may be disabled by
> -	  setting a value of 0.  This feature is reset whenever <ref
> -	  column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/>
> -	  changes.
> -	</column>
> -
> -	<column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'>
> +        </column>
> +
> +        <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'>
> +          An alternate receive interval, in milliseconds, that must be greater
> +          than or equal to <ref column="bfd" key="min_rx"/>.  The
> +          implementation switches from <ref column="bfd" key="min_rx"/> to <ref
> +          column="bfd" key="decay_min_rx"/> when there is no obvious incoming
> +          data traffic at the interface, to reduce the CPU and bandwidth cost
> +          of monitoring an idle interface.  This feature may be disabled by
> +          setting a value of 0.  This feature is reset whenever <ref
> +          column="bfd" key="decay_min_rx"/> or <ref column="bfd" key="min_rx"/>
> +          changes.
> +        </column>
> +
> +        <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'>
>           When <code>true</code>, traffic received on the
>           <ref table="Interface"/> is used to indicate the capability of packet
>           I/O.  BFD control packets are still transmitted and received.  At
> @@ -2490,98 +2490,98 @@
>           column="bfd" key="min_rx"/> amount of time.  Otherwise, even if
>           traffic are received, the <ref column="bfd" key="forwarding"/>
>           will be <code>false</code>.
> -	</column>
> +        </column>
> 
> -	<column name="bfd" key="cpath_down" type='{"type": "boolean"}'>
> -	  Set to true to notify the remote endpoint that traffic should not be
> -	  forwarded to this system for some reason other than a connectivty
> -	  failure on the interface being monitored.  The typical underlying
> -	  reason is ``concatenated path down,'' that is, that connectivity
> -	  beyond the local system is down.  Defaults to false.
> -	</column>
> +        <column name="bfd" key="cpath_down" type='{"type": "boolean"}'>
> +          Set to true to notify the remote endpoint that traffic should not be
> +          forwarded to this system for some reason other than a connectivty
> +          failure on the interface being monitored.  The typical underlying
> +          reason is ``concatenated path down,'' that is, that connectivity
> +          beyond the local system is down.  Defaults to false.
> +        </column>
> 
> -	<column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'>
> +        <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'>
>           Set to true to make BFD accept only control messages with a tunnel
>           key of zero.  By default, BFD accepts control messages with any
>           tunnel key.
> -	</column>
> -
> -	<column name="bfd" key="bfd_local_src_mac">
> -	  Set to an Ethernet address in the form
> -	  <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
> -	  to set the MAC used as source for transmitted BFD packets.  The
> -	  default is the mac address of the BFD enabled interface.
> -	</column>
> -
> -	<column name="bfd" key="bfd_local_dst_mac">
> -	  Set to an Ethernet address in the form
> -	  <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
> -	  to set the MAC used as destination for transmitted BFD packets.  The
> -	  default is <code>00:23:20:00:00:01</code>.
> -	</column>
> -
> -	<column name="bfd" key="bfd_remote_dst_mac">
> -	  Set to an Ethernet address in the form
> -	  <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
> -	  to set the MAC used for checking the destination of received BFD packets.
> -	  Packets with different destination MAC will not be considered as BFD packets.
> -	  If not specified the destination MAC address of received BFD packets
> -	  are not checked.
> -	</column>
> -
> -	<column name="bfd" key="bfd_src_ip">
> +        </column>
> +
> +        <column name="bfd" key="bfd_local_src_mac">
> +          Set to an Ethernet address in the form
> +          <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
> +          to set the MAC used as source for transmitted BFD packets.  The
> +          default is the mac address of the BFD enabled interface.
> +        </column>
> +
> +        <column name="bfd" key="bfd_local_dst_mac">
> +          Set to an Ethernet address in the form
> +          <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
> +          to set the MAC used as destination for transmitted BFD packets.  The
> +          default is <code>00:23:20:00:00:01</code>.
> +        </column>
> +
> +        <column name="bfd" key="bfd_remote_dst_mac">
> +          Set to an Ethernet address in the form
> +          <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
> +          to set the MAC used for checking the destination of received BFD packets.
> +          Packets with different destination MAC will not be considered as BFD packets.
> +          If not specified the destination MAC address of received BFD packets
> +          are not checked.
> +        </column>
> +
> +        <column name="bfd" key="bfd_src_ip">
>           Set to an IPv4 address to set the IP address used as source for
>           transmitted BFD packets.  The default is <code>169.254.1.1</code>.
> -	</column>
> +        </column>
> 
> -	<column name="bfd" key="bfd_dst_ip">
> +        <column name="bfd" key="bfd_dst_ip">
>           Set to an IPv4 address to set the IP address used as destination
>           for transmitted BFD packets.  The default is <code>169.254.1.0</code>.
> -	</column>
> +        </column>
>       </group>
> 
>       <group title="BFD Status">
> -	<p>
> -	  The switch sets key-value pairs in the <ref column="bfd_status"/>
> -	  column to report the status of BFD on this interface.  When BFD is
> -	  not enabled, with <ref column="bfd" key="enable"/>, the switch clears
> -	  all key-value pairs from <ref column="bfd_status"/>.
> -	</p>
> -
> -	<column name="bfd_status" key="state"
> -		type='{"type": "string",
> -		      "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
> -	  Reports the state of the BFD session.  The BFD session is fully
> -	  healthy and negotiated if <code>UP</code>.
> -	</column>
> -
> -	<column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
> -	  Reports whether the BFD session believes this <ref
> -	  table="Interface"/> may be used to forward traffic.  Typically this
> -	  means the local session is signaling <code>UP</code>, and the remote
> -	  system isn't signaling a problem such as concatenated path down.
> -	</column>
> -
> -	<column name="bfd_status" key="diagnostic">
> -	  In case of a problem, set to an error message that reports what the
> -	  local BFD session thinks is wrong.  The error messages are defined
> -	  in section 4.1 of [RFC 5880].
> -	</column>
> -
> -	<column name="bfd_status" key="remote_state"
> -		type='{"type": "string",
> -		      "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
> -	  Reports the state of the remote endpoint's BFD session.
> -	</column>
> -
> -	<column name="bfd_status" key="remote_diagnostic">
> -	  In case of a problem, set to an error message that reports what the
> -	  remote endpoint's BFD session thinks is wrong.  The error messages
> -	  are defined in section 4.1 of [RFC 5880].
> -	</column>
> +        <p>
> +          The switch sets key-value pairs in the <ref column="bfd_status"/>
> +          column to report the status of BFD on this interface.  When BFD is
> +          not enabled, with <ref column="bfd" key="enable"/>, the switch clears
> +          all key-value pairs from <ref column="bfd_status"/>.
> +        </p>
> +
> +        <column name="bfd_status" key="state"
> +                type='{"type": "string",
> +                      "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
> +          Reports the state of the BFD session.  The BFD session is fully
> +          healthy and negotiated if <code>UP</code>.
> +        </column>
> +
> +        <column name="bfd_status" key="forwarding" type='{"type": "boolean"}'>
> +          Reports whether the BFD session believes this <ref
> +          table="Interface"/> may be used to forward traffic.  Typically this
> +          means the local session is signaling <code>UP</code>, and the remote
> +          system isn't signaling a problem such as concatenated path down.
> +        </column>
> +
> +        <column name="bfd_status" key="diagnostic">
> +          In case of a problem, set to an error message that reports what the
> +          local BFD session thinks is wrong.  The error messages are defined
> +          in section 4.1 of [RFC 5880].
> +        </column>
> +
> +        <column name="bfd_status" key="remote_state"
> +                type='{"type": "string",
> +                      "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
> +          Reports the state of the remote endpoint's BFD session.
> +        </column>
> +
> +        <column name="bfd_status" key="remote_diagnostic">
> +          In case of a problem, set to an error message that reports what the
> +          remote endpoint's BFD session thinks is wrong.  The error messages
> +          are defined in section 4.1 of [RFC 5880].
> +        </column>
> 
>         <column name="bfd_status" key="flap_count"
> -          type='{"type": "integer", "minInteger": 0}'>
> +                type='{"type": "integer", "minInteger": 0}'>
>           Counts the number of <ref column="bfd_status" key="forwarding" />
>           flaps since start.  A flap is considered as a change of the
>           <ref column="bfd_status" key="forwarding" /> value.
> @@ -2609,9 +2609,9 @@
>       </p>
> 
>       <p>
> -          When operating over tunnels which have no <code>in_key</code>, or an
> -          <code>in_key</code> of <code>flow</code>.  CFM will only accept CCMs
> -          with a tunnel key of zero.
> +        When operating over tunnels which have no <code>in_key</code>, or an
> +        <code>in_key</code> of <code>flow</code>.  CFM will only accept CCMs
> +        with a tunnel key of zero.
>       </p>
> 
>       <column name="cfm_mpid">
> @@ -2696,8 +2696,8 @@
> 
>       <column name="cfm_remote_opstate">
>         <p>When in extended mode, indicates the operational state of the
> -          remote endpoint as either <code>up</code> or <code>down</code>.  See
> -          <ref column="other_config" key="cfm_opstate"/>.
> +        remote endpoint as either <code>up</code> or <code>down</code>.  See
> +        <ref column="other_config" key="cfm_opstate"/>.
>         </p>
>       </column>
> 
> @@ -2773,7 +2773,7 @@
>         </p>
> 
>         <p>
> -            Demand mode has a couple of caveats:
> +          Demand mode has a couple of caveats:
>           <ul>
>             <li>
>               To ensure that ovs-vswitchd has enough time to pull statistics
> @@ -2811,14 +2811,14 @@
>       </column>
> 
>       <column name="other_config" key="cfm_ccm_vlan"
> -        type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'>
> +              type='{"type": "integer", "minInteger": 1, "maxInteger": 4095}'>
>         When set, the CFM module will apply a VLAN tag to all CCMs it generates
>         with the given value.  May be the string <code>random</code> in which
>         case each CCM will be tagged with a different randomly generated VLAN.
>       </column>
> 
>       <column name="other_config" key="cfm_ccm_pcp"
> -        type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'>
> +              type='{"type": "integer", "minInteger": 1, "maxInteger": 7}'>
>         When set, the CFM module will apply a VLAN tag to all CCMs it generates
>         with the given PCP value, the VLAN ID of the tag is governed by the
>         value of <ref column="other_config" key="cfm_ccm_vlan"/>. If
> @@ -2926,17 +2926,17 @@
> 
>     <group title="VLAN Splinters">
>       <p>
> -	The ``VLAN splinters'' feature increases Open vSwitch compatibility
> -	with buggy network drivers in old versions of Linux that do not
> -	properly support VLANs when VLAN devices are not used, at some cost
> -	in memory and performance.
> +        The ``VLAN splinters'' feature increases Open vSwitch compatibility
> +        with buggy network drivers in old versions of Linux that do not
> +        properly support VLANs when VLAN devices are not used, at some cost
> +        in memory and performance.
>       </p>
> 
>       <p>
> -	When VLAN splinters are enabled on a particular interface, Open vSwitch
> -	creates a VLAN device for each in-use VLAN.  For sending traffic tagged
> -	with a VLAN on the interface, it substitutes the VLAN device.  Traffic
> -	received on the VLAN device is treated as if it had been received on
> +        When VLAN splinters are enabled on a particular interface, Open vSwitch
> +        creates a VLAN device for each in-use VLAN.  For sending traffic tagged
> +        with a VLAN on the interface, it substitutes the VLAN device.  Traffic
> +        received on the VLAN device is treated as if it had been received on
>         the interface on the particular VLAN.
>       </p>
> 
> @@ -2978,8 +2978,8 @@
>       </p>
> 
>       <p>
> -	VLAN splinters are deprecated.  When broken device drivers are no
> -	longer in widespread use, we will delete this feature.
> +        VLAN splinters are deprecated.  When broken device drivers are no
> +        longer in widespread use, we will delete this feature.
>       </p>
> 
>       <column name="other_config" key="enable-vlan-splinters"
> @@ -3004,12 +3004,12 @@
> 
>     <group title="Auto Attach Configuration">
>       <p>
> -          Auto Attach configuration for a particular interface.
> +        Auto Attach configuration for a particular interface.
>       </p>
> 
>       <column name="lldp" key="enable" type='{"type": "boolean"}'>
> -          True to enable LLDP on this <ref table="Interface"/>.  If not
> -          specified, LLDP will be disabled by default.
> +        True to enable LLDP on this <ref table="Interface"/>.  If not
> +        specified, LLDP will be disabled by default.
>       </column>
>     </group>
> 
> @@ -3986,7 +3986,7 @@
>       </p>
> 
>       <column name="other_config" key="dscp"
> -                type='{"type": "integer"}'>
> +              type='{"type": "integer"}'>
>         The Differentiated Service Code Point (DSCP) is specified using 6 bits
>         in the Type of Service (TOS) field in the IP header. DSCP provides a
>         mechanism to classify the network traffic and provide Quality of
> @@ -4252,11 +4252,11 @@
>       </column>
> 
>       <column name="status" key="bound_port" type='{"type": "integer"}'>
> -          When <ref column="target"/> is <code>ptcp:</code> or
> -          <code>pssl:</code>, this is the TCP port on which the OVSDB server is
> -          listening.  (This is is particularly useful when <ref
> -          column="target"/> specifies a port of 0, allowing the kernel to
> -          choose any available port.)
> +        When <ref column="target"/> is <code>ptcp:</code> or
> +        <code>pssl:</code>, this is the TCP port on which the OVSDB server is
> +        listening.  (This is is particularly useful when <ref
> +        column="target"/> specifies a port of 0, allowing the kernel to
> +        choose any available port.)
>       </column>
>     </group>
> 
> @@ -4267,7 +4267,7 @@
>       </p>
> 
>       <column name="other_config" key="dscp"
> -                type='{"type": "integer"}'>
> +              type='{"type": "integer"}'>
>         The Differentiated Service Code Point (DSCP) is specified using 6 bits
>         in the Type of Service (TOS) field in the IP header. DSCP provides a
>         mechanism to classify the network traffic and provide Quality of
> @@ -4312,18 +4312,18 @@
> 
>     <column name="active_timeout">
>       <p>
> -	The interval at which NetFlow records are sent for flows that
> -	are still active, in seconds.  A value of <code>0</code>
> -	requests the default timeout (currently 600 seconds); a value
> -	of <code>-1</code> disables active timeouts.
> +        The interval at which NetFlow records are sent for flows that
> +        are still active, in seconds.  A value of <code>0</code>
> +        requests the default timeout (currently 600 seconds); a value
> +        of <code>-1</code> disables active timeouts.
>       </p>
> 
>       <p>
> -	The NetFlow passive timeout, for flows that become inactive,
> -	is not configurable.  It will vary depending on the Open
> -	vSwitch version, the forms and contents of the OpenFlow flow
> -	tables, CPU and memory usage, and network activity.  A typical
> -	passive timeout is about a second.
> +        The NetFlow passive timeout, for flows that become inactive,
> +        is not configurable.  It will vary depending on the Open
> +        vSwitch version, the forms and contents of the OpenFlow flow
> +        tables, CPU and memory usage, and network activity.  A typical
> +        passive timeout is about a second.
>       </p>
>     </column>
> 
> @@ -4650,39 +4650,46 @@
>   </table>
> 
>   <table name="AutoAttach">
> -    <p>Auto Attach configuration within a bridge.  The IETF Auto-Attach SPBM
> -       draft standard describes a compact method of using IEEE 802.1AB Link
> -       Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest
> -       Path Bridging (SPB) network to automatically attach network devices
> -       to individual services in a SPB network.  The intent here is to allow
> -       network applications and devices using OVS to be able to easily take
> -       advantage of features offered by industry standard SPB networks.</p>
> -
> -    <p>Auto Attach (AA) uses LLDP to communicate between a directly connected
> -       Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol
> -       is extended to add two new Type-Length-Value tuples (TLVs). The first
> -       new TLV supports the ongoing discovery of directly connected AA
> -       correspondents. Auto Attach operates by regularly transmitting AA
> -       discovery TLVs between the AA client and AA server. By exchanging these
> -       discovery messages, both the AAC and AAS learn the system name and
> -       system description of their peer. In the OVS context, OVS operates as
> -       the AA client and the AA server resides on a switch at the edge of the
> -       SPB network.</p>
> -
> -     <p>Once AA discovery has been completed the AAC then uses the
> -       second new TLV to deliver identifier mappings from the AAC to the AAS. A primary
> -       feature of Auto Attach is to facilitate the mapping of VLANs defined
> -       outside the SPB network onto service ids (ISIDs) defined within the SPM
> -       network. By doing so individual external VLANs can be mapped onto
> -       specific SPB network services. These VLAN id to ISID mappings can be
> -       configured and managed locally using new options added to the ovs-vsctl
> -       command.</p>
> -
> -    <p>The Auto Attach OVS feature does not provide a full implementation of
> -       the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP
> -       standard and support for the AA TLV extensions is provided. LLDP
> -       protocol support in OVS can be enabled or disabled on a port by port
> -       basis. LLDP support is disabled by default.</p>
> +    <p>
> +      Auto Attach configuration within a bridge.  The IETF Auto-Attach SPBM
> +      draft standard describes a compact method of using IEEE 802.1AB Link
> +      Layer Discovery Protocol (LLDP) together with a IEEE 802.1aq Shortest
> +      Path Bridging (SPB) network to automatically attach network devices
> +      to individual services in a SPB network.  The intent here is to allow
> +      network applications and devices using OVS to be able to easily take
> +      advantage of features offered by industry standard SPB networks.
> +    </p>
> +
> +    <p>
> +      Auto Attach (AA) uses LLDP to communicate between a directly connected
> +      Auto Attach Client (AAC) and Auto Attach Server (AAS). The LLDP protocol
> +      is extended to add two new Type-Length-Value tuples (TLVs). The first
> +      new TLV supports the ongoing discovery of directly connected AA
> +      correspondents. Auto Attach operates by regularly transmitting AA
> +      discovery TLVs between the AA client and AA server. By exchanging these
> +      discovery messages, both the AAC and AAS learn the system name and
> +      system description of their peer. In the OVS context, OVS operates as
> +      the AA client and the AA server resides on a switch at the edge of the
> +      SPB network.
> +    </p>
> +
> +    <p>
> +      Once AA discovery has been completed the AAC then uses the second new TLV
> +      to deliver identifier mappings from the AAC to the AAS. A primary feature
> +      of Auto Attach is to facilitate the mapping of VLANs defined outside the
> +      SPB network onto service ids (ISIDs) defined within the SPM network. By
> +      doing so individual external VLANs can be mapped onto specific SPB
> +      network services. These VLAN id to ISID mappings can be configured and
> +      managed locally using new options added to the ovs-vsctl command.
> +    </p>
> +
> +    <p>
> +      The Auto Attach OVS feature does not provide a full implementation of
> +      the LLDP protocol. Support for the mandatory TLVs as defined by the LLDP
> +      standard and support for the AA TLV extensions is provided. LLDP
> +      protocol support in OVS can be enabled or disabled on a port by port
> +      basis. LLDP support is disabled by default.
> +    </p>
> 
>     <column name="system_name">
>       The system_name string is exported in LLDP messages.  It should uniquely
> @@ -4695,7 +4702,8 @@
>     </column>
> 
>     <column name="mappings">
> -      A mapping from SPB network Individual Service Identifier (ISID) to VLAN id.
> +      A mapping from SPB network Individual Service Identifier (ISID) to VLAN
> +      id.
>     </column>
>   </table>
> </database>
> -- 
> 2.1.3
> 




More information about the dev mailing list