[ovs-dev] [PATCH] vtep: Bring BFD specification in vtep.xml into sync with OVS.
Ben Pfaff
blp at nicira.com
Tue Oct 29 20:51:20 UTC 2013
Applied, thanks.
On Tue, Oct 29, 2013 at 01:34:46PM -0700, Bruce Davie wrote:
> This patch looks good, thanks.
>
> Bruce
>
> On Oct 29, 2013, at 1:02 PM, Ben Pfaff wrote:
>
> > 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.
> >
> > CC: Bruce Davie <bdavie at nicira.com>
> > Signed-off-by: Ben Pfaff <blp at nicira.com>
> > ---
> > vtep/vtep.xml | 178 ++++++++++++++++++++++++++++++++++++++++-----------------
> > 1 file changed, 127 insertions(+), 51 deletions(-)
> >
> > diff --git a/vtep/vtep.xml b/vtep/vtep.xml
> > index 9fd7495..3940479 100644
> > --- a/vtep/vtep.xml
> > +++ b/vtep/vtep.xml
> > @@ -644,11 +644,12 @@
> > encapsulations to be introduced later.
> > </p>
> > </column>
> > +
> > <group title="Bidirectional Forwarding Detection (BFD)">
> > <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,60 +658,135 @@
> > 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>
> >
> > - <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
> > - if the remote endpoint isn't willing to transmit as quickly as
> > - specified. Defaults to <code>1000</code>.
> > - </column>
> > -
> > - <column name="bfd" key="min_tx">
> > - The minimum rate, in milliseconds, at which this BFD session is
> > - willing to transmit BFD control messages. The actual rate may be
> > - slower if the remote endpoint isn't willing to receive as quickly as
> > - specified. Defaults to <code>100</code>.
> > - </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
> > - 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_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>
> > -
> > - <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.
> > - </column>
> > -
> > - <column name="bfd_status" key="diagnostic">
> > - A short message indicating what the BFD session thinks is wrong in
> > - case of a problem.
> > - </column>
> > -
> > - <column name="bfd_status" key="remote state">
> > - State of the remote endpoint's BFD session.
> > - </column>
> > -
> > - <column name="bfd_status" key="remote diagnostic">
> > - A short message indicating what the remote endpoint's BFD session
> > - thinks is wrong in case of a problem.
> > - </column>
> > + <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>
> > +
> > + <group title="BFD Configuration">
> > + <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"}'>
> > + True to enable BFD on this <ref table="Physical_Locator"/>.
> > + </column>
> > +
> > + <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 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"}'>
> > + True to consider the interface capable of packet I/O as long as it
> > + continues to receive any packets (not just BFD packets). This
> > + prevents link congestion that causes consecutive BFD control packets
> > + to be lost from marking the interface down.
> > + </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"}'>
> > + 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_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 and
> > + expected as destination for received BFD packets. The default is
> > + <code>00:23:20:00:00:01</code>.
> > + </column>
> > + </group>
> > +
> > + <group title="BFD Status">
> > + <p>
> > + The VTEP 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="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">
> > + In case of a problem, set to a short message that reports what the
> > + local BFD session thinks is wrong.
> > + </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 a short message that reports what the
> > + remote endpoint's BFD session thinks is wrong.
> > + </column>
> > + </group>
> > </group>
> > </table>
> >
> > --
> > 1.7.10.4
> >
>
More information about the dev
mailing list