[ovs-dev] [PATCH] vtep: Bring BFD specification in vtep.xml into sync with OVS.
Bruce Davie
bdavie at nicira.com
Thu Oct 24 15:30:51 UTC 2013
A number of new key-value pairs have been added to the bfd and bfd_status
columns of the OVS schema since the VTEP schema was created. To aid
interoperability between OVS instances and VTEPs, this patch brings
the VTEP schema into line with that of OVS.
Signed-off-by: Bruce Davie <bdavie at vmware.com>
---
vtep/vtep.xml | 88 +++++++++++++++++++++++++++++++++++++++++++++++++++--------
1 file changed, 76 insertions(+), 12 deletions(-)
diff --git a/vtep/vtep.xml b/vtep/vtep.xml
index 9fd7495..60f4025 100644
--- a/vtep/vtep.xml
+++ b/vtep/vtep.xml
@@ -648,7 +648,7 @@
<p>
BFD, defined in RFC 5880, allows point to point detection of
connectivity failures by occasional transmission of BFD control
- messages.
+ messages. VTEPs are expected to implement BFD.
</p>
<p>
@@ -657,15 +657,39 @@
specifies the rate at which it expects to receive control messages,
and the rate at which it's willing to transmit them. An endpoint
which fails to receive BFD control messages for a period of three
- times the expected reception rate, will signal a connectivity
+ times the expected reception rate will signal a connectivity
fault. In the case of a unidirectional connectivity issue, the
system not receiving BFD control messages will signal the problem
- to its peer in the messages is transmists.
+ to its peer in the messages it transmits.
</p>
+ <p>
+ A hardware VTEP is expected to use BFD to determine
+ reachability of devices at the end of the tunnels with which
+ it exchanges data. This can enable the VTEP to choose a
+ functioning service node among a set of service nodes
+ providing high availability. It also enables the NVC to report the
+ health status of tunnels.
+ </p>
+
+ <p>
+ In most cases the BFD peer of a hardware VTEP will be an Open
+ vSwitch instance. The Open vSwitch implementation of BFD aims
+ to comply faithfully with the requirements put forth in RFC
+ 5880. Open vSwitch does not implement the optional
+ Authentication or "Echo Mode" features.
+ </p>
+
+
+ <column name="bfd" key="enable">
+ When <code>true</code> BFD is enabled on this
+ <ref table="Physical_Locator"/>, otherwise it's disabled. Defaults to
+ <code>false</code>.
+ </column>
+
<column name="bfd" key="min_rx">
The minimum rate, in milliseconds, at which this BFD session is
- willing to receive BFD control messages. The actual rate may slower
+ willing to receive BFD control messages. The actual rate may be slower
if the remote endpoint isn't willing to transmit as quickly as
specified. Defaults to <code>1000</code>.
</column>
@@ -676,26 +700,66 @@
slower if the remote endpoint isn't willing to receive as quickly as
specified. Defaults to <code>100</code>.
</column>
+
+ <column name="bfd" key="decay_min_rx" type='{"type": "integer"}'>
+ <code>decay_min_rx</code> is used to set the
+ <code>min_rx</code>, when there is no obvious incoming data
+ traffic at the interface. It cannot be set less than the
+ <code>min_rx</code>. The decay feature is disabled by setting
+ the <code>decay_min_rx</code> to 0. The feature is reset every
+ time <code>decay_min_rx</code> or <code>min_rx</code> is
+ reconfigured.
+ </column>
+ <column name="bfd" key="forwarding_if_rx" type='{"type": "boolean"}'>
+ When <code>forwarding_if_rx</code> is true, the interface
+ should be considered capable of packet I/O as long as packets
+ are being received at interface. This is important in that
+ when a link becomes temporarily congested, consecutive BFD
+ control packets can be lost. Enabling
+ <code>forwarding_if_rx</code> can prevent link fail-over by
+ detecting non-control packets received at interface.
+ </column>
+
<column name="bfd" key="cpath_down">
Concatenated path down may be used when the local system should not
- have traffic forwarded to it for some reason other than a connectivty
+ have traffic forwarded to it for some reason other than a connectivity
failure on the interface being monitored. The local BFD session will
notify the remote session of the connectivity problem, at which time
the remote session may choose not to forward traffic. Defaults to
<code>false</code>.
</column>
+
+ <column name="bfd" key="check_tnl_key" type='{"type": "boolean"}'>
+ When set to true, Check Tunnel Key will make BFD only accept control
+ messages with an <code>in_key</code> of zero. Defaults to
+ <code>false</code>.
+ </column>
+
+ <column name="bfd" key="bfd_dst_mac">
+ An Ethernet address in the form
+ <var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>:<var>xx</var>
+ may be provided by the NSC to set the destination mac address
+ of BFD packets. If this field is set, it is expected that all
+ the BFD packets sent over this tunnel will carry this
+ destination mac address. If not set, a default value of
+ <code>00:23:20:00:00:01</code> should be used.
+ </column>
+
- <column name="bfd_status" key="state">
- State of the BFD session. One of <code>ADMIN_DOWN</code>,
- <code>DOWN</code>, <code>INIT</code>, or <code>UP</code>.
+ <column name="bfd_status" key="state"
+ type='{"type": "string",
+ "enum": ["set", ["admin_down", "down", "init", "up"]]}'>
+ State of the BFD session. The BFD session is fully healthy and
+ negotiated if <code>UP</code>.
</column>
<column name="bfd_status" key="forwarding">
- True if the BFD session believes this <ref table="Physical_Locator"/> may be
- used to forward traffic. Typically this means the local session is
- up, and the remote system isn't signalling a problem such as
- concatenated path down.
+ True if the BFD session believes this <ref
+ table="Physical_Locator"/> 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">
--
1.8.0.2
More information about the dev
mailing list