[ovs-dev] [PATCH ovn] Rename "VTEP switch" to "ramp switch".
Numan Siddique
numans at ovn.org
Sun Mar 29 18:02:32 UTC 2020
On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <blp at ovn.org> wrote:
>
> The term "VTEP" is a poor choice because a VTEP is just a VXLAN Tunnel
> Endpoint, which is a generic term not specific to OVN. When we talk
> about "VTEP switches" and "VTEP gateways", therefore, it's somewhat
> confusing.
>
> This commit introduces the term "ramp", which uses the metaphor of one
> of these switches as an on-ramp and an off-ramp to an OVN logical
> network, and substitutes it wherever it can be in the documentation.
> Bits of the OVN database are harder to change, since changing them
> would cause backward compatibility problems, so this commit doesn't try.
>
> It might be a good idea to change some program names (e.g.
> ovn-controller-vtep), some distro package names, and so on. This commit
> does not do that.
>
> CC: Ihar Hrachyshka <ihrachys at redhat.com>
> Signed-off-by: Ben Pfaff <blp at ovn.org>
Acked-by: Numan Siddique <numans at ovn.org>
I think it's better to rename ovn-controller-vtep to ovn-controller-ramp
(or ovn-ramp-controller ?)
If the rename is fine, I can work on that once this patch is merged.
Thanks
Numan
> ---
> Documentation/faq/general.rst | 10 +--
> Documentation/topics/high-availability.rst | 10 +--
> Documentation/tutorials/ovn-openstack.rst | 2 +-
> NEWS | 2 +
> controller/physical.c | 15 ++--
> include/ovn/logical-fields.h | 10 ++-
> northd/ovn-northd.c | 13 ++--
> ovn-architecture.7.xml | 84 ++++++++++++----------
> ovn-nb.xml | 12 ++--
> ovn-sb.xml | 19 ++---
> utilities/ovn-nbctl.8.xml | 2 +-
> 11 files changed, 97 insertions(+), 82 deletions(-)
>
> diff --git a/Documentation/faq/general.rst b/Documentation/faq/general.rst
> index 831ca0445d08..c1b0a6907771 100644
> --- a/Documentation/faq/general.rst
> +++ b/Documentation/faq/general.rst
> @@ -108,10 +108,12 @@ Q: Why does OVN use STT and Geneve instead of VLANs or VXLAN (or GRE)?
> may need to allocate more bits to the datapath or egress port
> identifiers.
>
> - As a side note, OVN does support VXLAN for use with ASIC-based top of rack
> - switches, using ``ovn-controller-vtep(8)`` and the OVSDB VTEP schema
> - described in ``vtep(5)``, but this limits the features available from OVN
> - to the subset available from the VTEP schema.
> + As a side note, OVN does support VXLAN for use with "ramp
> + gateways" that allow ASIC-based top of rack switches to act as
> + on-ramp from a physical network into an OVN logical network. Ramp
> + switches use ``ovn-controller-vtep(8)`` and the OVSDB VTEP schema
> + described in ``vtep(5)``. This limits the features available from
> + OVN to the subset available from the VTEP schema.
>
> Q: How can I contribute to the OVN Community?
>
> diff --git a/Documentation/topics/high-availability.rst b/Documentation/topics/high-availability.rst
> index c3c962c1d045..9f1d94722ee2 100644
> --- a/Documentation/topics/high-availability.rst
> +++ b/Documentation/topics/high-availability.rst
> @@ -52,11 +52,11 @@ OVN Gateway High Availability Plan
>
> The OVN gateway is responsible for shuffling traffic between the tunneled
> overlay network (governed by ovn-northd), and the legacy physical network. In
> -a naive implementation, the gateway is a single x86 server, or hardware VTEP.
> -For most deployments, a single system has enough forwarding capacity to service
> -the entire virtualized network, however, it introduces a single point of
> -failure. If this system dies, the entire OVN deployment becomes unavailable.
> -To mitigate this risk, an HA solution is critical -- by spreading
> +a naive implementation, the gateway is a single x86 server or a hardware ToR
> +switch. For most deployments, a single system has enough forwarding capacity
> +to service the entire virtualized network, however, it introduces a single
> +point of failure. If this system dies, the entire OVN deployment becomes
> +unavailable. To mitigate this risk, an HA solution is critical -- by spreading
> responsibility across multiple systems, no single server failure can take down
> the network.
>
> diff --git a/Documentation/tutorials/ovn-openstack.rst b/Documentation/tutorials/ovn-openstack.rst
> index 2e4f63404670..e5356dad6f4f 100644
> --- a/Documentation/tutorials/ovn-openstack.rst
> +++ b/Documentation/tutorials/ovn-openstack.rst
> @@ -1959,4 +1959,4 @@ explore some of these directions:
>
> * Other kinds of gateways. In addition to floating IPs with NAT, OVN
> supports directly attaching VMs to a physical network and connecting
> - logical switches to VTEP hardware.
> + logical switches to hardware top-of-rack switches.
> diff --git a/NEWS b/NEWS
> index 393721d70111..cb322d03ee6b 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -1,5 +1,7 @@
> Post-v20.03.0
> --------------------------
> + - "VTEP" gateways and switches have been renamed "ramp" gateways and
> + switches, to better distinguish them from everyday use of VXLAN.
>
>
> OVN v20.03.0 - xx xxx xxxx
> diff --git a/controller/physical.c b/controller/physical.c
> index 144aeb7bdd7c..f33292275f2c 100644
> --- a/controller/physical.c
> +++ b/controller/physical.c
> @@ -1668,9 +1668,8 @@ physical_run(struct physical_ctx *p_ctx,
> ofpbuf_clear(&ofpacts);
> put_move(MFF_TUN_ID, 0, MFF_LOG_DATAPATH, 0, 24, &ofpacts);
> put_load(binding->tunnel_key, MFF_LOG_INPORT, 0, 15, &ofpacts);
> - /* For packets received from a vxlan tunnel, set a flag to that
> - * effect. */
> - put_load(1, MFF_LOG_FLAGS, MLF_RCV_FROM_VXLAN_BIT, 1, &ofpacts);
> + /* Packets received from a VXLAN tunnel lack an egress port. */
> + put_load(1, MFF_LOG_FLAGS, MLF_NO_EGRESS_PORT_BIT, 1, &ofpacts);
> put_resubmit(OFTABLE_LOG_INGRESS_PIPELINE, &ofpacts);
>
> ofctrl_add_flow(flow_table, OFTABLE_PHY_TO_LOG, 100,
> @@ -1682,15 +1681,15 @@ physical_run(struct physical_ctx *p_ctx,
> /* Table 32, priority 150.
> * =======================
> *
> - * Handles packets received from a VXLAN tunnel which get resubmitted to
> - * OFTABLE_LOG_INGRESS_PIPELINE due to lack of needed metadata in VXLAN,
> - * explicitly skip sending back out any tunnels and resubmit to table 33
> - * for local delivery.
> + * For packets received without an egress port (e.g. from a VXLAN tunnel),
> + * resubmit them to OFTABLE_LOG_INGRESS_PIPELINE to rediscover the egress
> + * port, but explicitly skip sending back out any tunnels and resubmit to
> + * table 33 for local delivery.
> */
> struct match match;
> match_init_catchall(&match);
> match_set_reg_masked(&match, MFF_LOG_FLAGS - MFF_REG0,
> - MLF_RCV_FROM_VXLAN, MLF_RCV_FROM_VXLAN);
> + MLF_NO_EGRESS_PORT, MLF_NO_EGRESS_PORT);
>
> /* Resubmit to table 33. */
> ofpbuf_clear(&ofpacts);
> diff --git a/include/ovn/logical-fields.h b/include/ovn/logical-fields.h
> index c7bd2dba9374..d210edf694dd 100644
> --- a/include/ovn/logical-fields.h
> +++ b/include/ovn/logical-fields.h
> @@ -51,7 +51,7 @@ void ovn_init_symtab(struct shash *symtab);
> /* MFF_LOG_FLAGS_REG bit assignments */
> enum mff_log_flags_bits {
> MLF_ALLOW_LOOPBACK_BIT = 0,
> - MLF_RCV_FROM_VXLAN_BIT = 1,
> + MLF_NO_EGRESS_PORT_BIT = 1,
> MLF_FORCE_SNAT_FOR_DNAT_BIT = 2,
> MLF_FORCE_SNAT_FOR_LB_BIT = 3,
> MLF_LOCAL_ONLY_BIT = 4,
> @@ -64,11 +64,9 @@ enum mff_log_flags {
> /* Allow outputting back to inport. */
> MLF_ALLOW_LOOPBACK = (1 << MLF_ALLOW_LOOPBACK_BIT),
>
> - /* Indicate that a packet was received from a VXLAN tunnel to
> - * compensate for the lack of egress port information available in
> - * VXLAN encapsulation. Egress port information is available for
> - * Geneve and STT tunnel types. */
> - MLF_RCV_FROM_VXLAN = (1 << MLF_RCV_FROM_VXLAN_BIT),
> + /* Indicate that a packet was received without egress port information,
> + * which is not available, e.g., in packets received from ramp switches. */
> + MLF_NO_EGRESS_PORT = (1 << MLF_NO_EGRESS_PORT_BIT),
>
> /* Indicate that a packet needs a force SNAT in the gateway router when
> * DNAT has taken place. */
> diff --git a/northd/ovn-northd.c b/northd/ovn-northd.c
> index f648d2ea72c0..7c0c654e1999 100644
> --- a/northd/ovn-northd.c
> +++ b/northd/ovn-northd.c
> @@ -225,7 +225,7 @@ enum ovn_stage {
> #define REG_ECMP_GROUP_ID "reg8[0..15]"
> #define REG_ECMP_MEMBER_ID "reg8[16..31]"
>
> -#define FLAGBIT_NOT_VXLAN "flags[1] == 0"
> +#define FLAGBIT_HAS_EGRESS_PORT "flags[1] == 0"
>
> /* Returns an "enum ovn_stage" built from the arguments. */
> static enum ovn_stage
> @@ -5880,12 +5880,13 @@ build_lswitch_rport_arp_req_flow_for_ip(struct sset *ips,
> struct ds match = DS_EMPTY_INITIALIZER;
> struct ds actions = DS_EMPTY_INITIALIZER;
>
> - /* Packets received from VXLAN tunnels have already been through the
> - * router pipeline so we should skip them. Normally this is done by the
> - * multicast_group implementation (VXLAN packets skip table 32 which
> - * delivers to patch ports) but we're bypassing multicast_groups.
> + /* Packets that have an egress port have already been through the router
> + * pipeline so we should skip them. Normally this is done by the
> + * multicast_group implementation (packets lacking an egress port skip
> + * table 32 which delivers to patch ports) but we're bypassing
> + * multicast_groups.
> */
> - ds_put_cstr(&match, FLAGBIT_NOT_VXLAN " && ");
> + ds_put_cstr(&match, FLAGBIT_HAS_EGRESS_PORT" && ");
>
> if (addr_family == AF_INET) {
> ds_put_cstr(&match, "arp.op == 1 && arp.tpa == { ");
> diff --git a/ovn-architecture.7.xml b/ovn-architecture.7.xml
> index 533ae716d11d..a415ad0e42f4 100644
> --- a/ovn-architecture.7.xml
> +++ b/ovn-architecture.7.xml
> @@ -77,8 +77,8 @@
> logical network into a physical network by bidirectionally forwarding
> packets between tunnels and a physical Ethernet port. This allows
> non-virtualized machines to participate in logical networks. A gateway
> - may be a physical host, a virtual machine, or an ASIC-based hardware
> - switch that supports the <code>vtep</code>(5) schema.
> + may be a physical host, a virtual machine, or a hardware switch (see
> + <code>Ramp Gateways</code>, below).
> </p>
>
> <p>
> @@ -529,20 +529,27 @@
> ones. OVN support multiple kinds of gateways.
> </p>
>
> - <h3>VTEP Gateways</h3>
> + <h3>Ramp Gateways</h3>
>
> <p>
> - A ``VTEP gateway'' connects an OVN logical network to a physical (or
> - virtual) switch that implements the OVSDB VTEP schema that accompanies Open
> - vSwitch. (The ``VTEP gateway'' term is a misnomer, since a VTEP is just a
> - VXLAN Tunnel Endpoint, but it is a well established name.) See <code>Life
> - Cycle of a VTEP gateway</code>, below, for more information.
> + A ``ramp gateway'' acts like an on-ramp to an OVN logical network from a
> + physical (or virtual) switch, called a ``ramp switch'', that implements the
> + OVSDB VTEP schema that accompanies Open vSwitch. See <code>Life Cycle of a
> + ramp gateway</code>, below, for more information.
> </p>
>
> <p>
> - The main intended use case for VTEP gateways is to attach physical servers
> - to an OVN logical network using a physical top-of-rack switch that supports
> - the OVSDB VTEP schema.
> + The main intended use case for ramp gateways is to attach physical servers
> + to an OVN logical network using a physical top-of-rack switch instead of a
> + server. Reasons to do this include convenience (the switch is already
> + there and supports this feature) or density (the switch has 40 ports and
> + it's difficult to add that many to a server).
> + </p>
> +
> + <p>
> + Previous versions of OVN referred to ramp gateways and ramp switches as
> + ``VTEP gateways'' and ``VTEP switches,'' respectively, but these terms are
> + misnomers, since a VTEP is just a VXLAN Tunnel Endpoint.
> </p>
>
> <h3>L2 Gateways</h3>
> @@ -568,7 +575,7 @@
> the transport between hypervisors. With an L2 gateway, packets are still
> transported between hypervisors over tunnels and the <code>l2gateway</code>
> port is only used for the packets that are on the physical network. The
> - application for L2 gateways is similar to that for VTEP gateways, e.g. to
> + application for L2 gateways is similar to that for ramp gateways, e.g. to
> add non-virtualized machines to a logical network, but L2 gateways do not
> require special support from top-of-rack hardware switches.
> </p>
> @@ -1134,7 +1141,7 @@
> <p>
> Geneve and STT tunnels pass this field as part of the tunnel key.
> Although VXLAN tunnels do not explicitly carry a logical input port,
> - OVN only uses VXLAN to communicate with gateways that from OVN's
> + OVN only uses VXLAN to communicate with ramp gateways, which from OVN's
> perspective consist of only a single logical port, so that OVN can set
> the logical input port field to this one on ingress to the OVN logical
> pipeline.
> @@ -1160,7 +1167,7 @@
> an OVN hypervisor, the packet is resubmitted to table 8 to
> determine the output port(s); when the packet reaches table 32,
> these packets are resubmitted to table 33 for local delivery by
> - checking a MLF_RCV_FROM_VXLAN flag, which is set when the packet
> + checking a MLF_NO_EGRESS_PORT flag, which is set when the packet
> arrives from a VXLAN tunnel.
> </p>
> </dd>
> @@ -1399,12 +1406,12 @@
>
> <ul>
> <li>
> - A higher-priority rule to match packets received from VXLAN tunnels,
> - based on flag MLF_RCV_FROM_VXLAN, and resubmit these packets to table
> - 33 for local delivery. Packets received from VXLAN tunnels reach
> - here because of a lack of logical output port field in the tunnel key
> - and thus these packets needed to be submitted to table 8 to
> - determine the output port.
> + A higher-priority rule to match packets that were received without
> + egress port metadata, based on flag MLF_NO_EGRESS_PORT. The actions
> + resubmit these packets to table 33 for local delivery. This catches
> + packets received from VXLAN tunnels because of a lack of logical
> + output port field in the tunnel key and thus these packets needed to
> + be submitted to table 8 to determine the output port.
> </li>
> <li>
> A higher-priority rule to match packets received from ports of type
> @@ -2062,12 +2069,15 @@
> </ol>
>
>
> - <h2>Life Cycle of a VTEP gateway</h2>
> + <h2>Life Cycle of a ramp gateway</h2>
>
> <p>
> - A gateway is a chassis that forwards traffic between the OVN-managed
> - part of a logical network and a physical VLAN, extending a
> - tunnel-based logical network into a physical network.
> + A gateway is a chassis that forwards traffic between the OVN-managed part
> + of a logical network and a physical VLAN, extending a tunnel-based logical
> + network into a physical network. A ``ramp gateway'' acts like an on-ramp
> + to an OVN logical network from a physical (or virtual) switch, called a
> + ``ramp switch'', that implements the OVSDB VTEP schema that accompanies
> + Open vSwitch. See <code>Ramp Gateways</code>, above, for more information.
> </p>
>
> <p>
> @@ -2079,19 +2089,19 @@
>
> <ol>
> <li>
> - A VTEP gateway's life cycle begins with the administrator registering
> - the VTEP gateway as a <code>Physical_Switch</code> table entry in the
> + A ramp gateway's life cycle begins with the administrator registering
> + the ramp gateway as a <code>Physical_Switch</code> table entry in the
> <code>VTEP</code> database. The <code>ovn-controller-vtep</code>
> - connected to this VTEP database, will recognize the new VTEP gateway
> + connected to this VTEP database, will recognize the new ramp gateway
> and create a new <code>Chassis</code> table entry for it in the
> <code>OVN_Southbound</code> database.
> </li>
>
> <li>
> The administrator can then create a new <code>Logical_Switch</code>
> - table entry, and bind a particular vlan on a VTEP gateway's port to
> + table entry, and bind a particular vlan on a ramp gateway's port to
> any VTEP logical switch. Once a VTEP logical switch is bound to
> - a VTEP gateway, the <code>ovn-controller-vtep</code> will detect
> + a ramp gateway, the <code>ovn-controller-vtep</code> will detect
> it and add its name to the <var>vtep_logical_switches</var>
> column of the <code>Chassis</code> table in the <code>
> OVN_Southbound</code> database. Note, the <var>tunnel_key</var>
> @@ -2108,7 +2118,7 @@
> of this entry must be set to "vtep". Next, the <var>
> vtep-logical-switch</var> and <var>vtep-physical-switch</var> keys
> in the <var>options</var> column must also be specified, since
> - multiple VTEP gateways can attach to the same VTEP logical switch.
> + multiple ramp gateways can attach to the same VTEP logical switch.
> </li>
>
> <li>
> @@ -2116,14 +2126,14 @@
> database and its configuration will be passed down to the <code>
> OVN_Southbound</code> database as a new <code>Port_Binding</code>
> table entry. The <code>ovn-controller-vtep</code> will recognize the
> - change and bind the logical port to the corresponding VTEP gateway
> + change and bind the logical port to the corresponding ramp gateway
> chassis. Configuration of binding the same VTEP logical switch to
> a different OVN logical networks is not allowed and a warning will be
> generated in the log.
> </li>
>
> <li>
> - Beside binding to the VTEP gateway chassis, the <code>
> + Beside binding to the ramp gateway chassis, the <code>
> ovn-controller-vtep</code> will update the <var>tunnel_key</var>
> column of the VTEP logical switch to the corresponding <code>
> Datapath_Binding</code> table entry's <var>tunnel_key</var> for the
> @@ -2135,13 +2145,13 @@
> configuration change in the <code>Port_Binding</code> in the
> <code>OVN_Northbound</code> database, and updating the
> <code>Ucast_Macs_Remote</code> table in the <code>VTEP</code> database.
> - This allows the VTEP gateway to understand where to forward the unicast
> + This allows the ramp gateway to understand where to forward the unicast
> traffic coming from the extended external network.
> </li>
>
> <li>
> - Eventually, the VTEP gateway's life cycle ends when the administrator
> - unregisters the VTEP gateway from the <code>VTEP</code> database.
> + Eventually, the ramp gateway's life cycle ends when the administrator
> + unregisters the ramp gateway from the <code>VTEP</code> database.
> The <code>ovn-controller-vtep</code> will recognize the event and
> remove all related configurations (<code>Chassis</code> table entry
> and port bindings) in the <code>OVN_Southbound</code> database.
> @@ -2151,7 +2161,7 @@
> When the <code>ovn-controller-vtep</code> is terminated, all related
> configurations in the <code>OVN_Southbound</code> database and
> the <code>VTEP</code> database will be cleaned, including
> - <code>Chassis</code> table entries for all registered VTEP gateways
> + <code>Chassis</code> table entries for all registered ramp gateways
> and their port bindings, and all <code>Ucast_Macs_Remote</code> table
> entries and the <code>Logical_Switch</code> tunnel keys.
> </li>
> @@ -2658,7 +2668,7 @@
> </diagram>
>
> <p>
> - For connecting to gateways, in addition to Geneve and STT, OVN supports
> + For connecting to ramp gateways, in addition to Geneve and STT, OVN supports
> VXLAN, because only VXLAN support is common on top-of-rack (ToR) switches.
> Currently, gateways have a feature set that matches the capabilities as
> defined by the VTEP schema, so fewer bits of metadata are necessary. In
> diff --git a/ovn-nb.xml b/ovn-nb.xml
> index f4ecc1c1ec03..e726996423c4 100644
> --- a/ovn-nb.xml
> +++ b/ovn-nb.xml
> @@ -549,7 +549,7 @@
>
> <dt><code>vtep</code></dt>
> <dd>
> - A port to a logical switch on a VTEP gateway.
> + A port to a logical switch on a ramp gateway.
> </dd>
>
> <dt><code>external</code></dt>
> @@ -746,17 +746,19 @@
>
> </group>
>
> - <group title="Options for vtep ports">
> + <group title="Options for ramp ports">
> <p>
> - These options apply when <ref column="type"/> is <code>vtep</code>.
> + These options apply when <ref column="type"/> is <code>vtep</code>,
> + that is, when the port is used to attach a ramp gateway to an OVN
> + logical switch.
> </p>
>
> <column name="options" key="vtep-physical-switch">
> - Required. The name of the VTEP gateway.
> + Required. The name of the ramp gateway.
> </column>
>
> <column name="options" key="vtep-logical-switch">
> - Required. A logical switch name connected by the VTEP gateway.
> + Required. A logical switch name connected by the ramp gateway.
> </column>
> </group>
>
> diff --git a/ovn-sb.xml b/ovn-sb.xml
> index 3ae9d4f92b18..98d3ba0071f9 100644
> --- a/ovn-sb.xml
> +++ b/ovn-sb.xml
> @@ -354,7 +354,7 @@
> </p>
>
> <column name="vtep_logical_switches">
> - Stores all VTEP logical switch names connected by this gateway
> + Stores all ramp logical switch names connected by this gateway
> chassis. The <ref table="Port_Binding"/> table entry with
> <ref column="options" table="Port_Binding"/>:<code>vtep-physical-switch</code>
> equal <ref table="Chassis"/> <ref column="name" table="Chassis"/>, and
> @@ -417,7 +417,7 @@
>
> <p>
> Not all devices see such a benefit. The most notable exception is
> - hardware VTEPs. These devices are designed to not buffer entire
> + ramp switches. These devices are designed to not buffer entire
> packets in their switching engines and are therefore unable to
> efficiently compute or validate full packet checksums. In addition
> certain versions of the Linux kernel are not able to fully take
> @@ -428,7 +428,7 @@
> </p>
>
> <p>
> - <code>csum</code> defaults to <code>false</code> for hardware VTEPs and
> + <code>csum</code> defaults to <code>false</code> for ramp switches and
> <code>true</code> for all other cases.
> </p>
>
> @@ -2494,7 +2494,7 @@ tcp.flags = RST;
>
> <dt>vtep</dt>
> <dd>
> - The physical location of the hardware_vtep gateway. To successfully
> + The physical location of the ramp gateway. To successfully
> identify a chassis, this column must be a <ref table="Chassis"/> record.
> This is populated by <code>ovn-controller-vtep</code>.
> </dd>
> @@ -2631,7 +2631,7 @@ tcp.flags = RST;
>
> <dt><code>vtep</code></dt>
> <dd>
> - A port to a logical switch on a VTEP gateway chassis. In order to
> + A port to a logical switch on a ramp gateway chassis. In order to
> get this port correctly recognized by the OVN controller, the <ref
> column="options"
> table="Port_Binding"/>:<code>vtep-physical-switch</code> and <ref
> @@ -2802,18 +2802,19 @@ tcp.flags = RST;
> </column>
> </group>
>
> - <group title="VTEP Options">
> + <group title="Ramp Switch Options">
> <p>
> These options apply to logical ports with <ref column="type"/> of
> - <code>vtep</code>.
> + <code>vtep</code>, that is, ports that attach a ramp gateway to an OVN
> + logical switch.
> </p>
>
> <column name="options" key="vtep-physical-switch">
> - Required. The name of the VTEP gateway.
> + Required. The name of the ramp gateway.
> </column>
>
> <column name="options" key="vtep-logical-switch">
> - Required. A logical switch name connected by the VTEP gateway. Must
> + Required. A logical switch name connected by the ramp gateway. Must
> be set when <ref column="type"/> is <code>vtep</code>.
> </column>
> </group>
> diff --git a/utilities/ovn-nbctl.8.xml b/utilities/ovn-nbctl.8.xml
> index d973be25970d..7a734a494df4 100644
> --- a/utilities/ovn-nbctl.8.xml
> +++ b/utilities/ovn-nbctl.8.xml
> @@ -429,7 +429,7 @@
>
> <dt><code>vtep</code></dt>
> <dd>
> - A port to a logical switch on a VTEP gateway.
> + A port to a logical switch on a ramp gateway.
> </dd>
> </dl>
>
> --
> 2.24.1
>
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>
More information about the dev
mailing list