Thanks, applied.
On Tue, Oct 13, 2015 at 04:16:41PM -0700, Justin Pettit wrote:
> Thanks!
>
> Acked-by: Justin Pettit <jpet...@nicira.com>
>
> --Justin
>
>
> > On Oct 13, 2015, at 4:15 PM, Ben Pfaff <b...@nicira.com> wrote:
> >
> > This is a large patch but it is entirely whitespace changes.
> >
> > Suggested-by: Justin Pettit <jpet...@nicira.com>
> > Signed-off-by: Ben Pfaff <b...@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
> >
>
_______________________________________________
dev mailing list
dev@openvswitch.org
http://openvswitch.org/mailman/listinfo/dev
