[ovs-dev,ovn] Rename "VTEP switch" to "ramp switch".

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@redhat.com>
Signed-off-by: Ben Pfaff <blp@ovn.org>
---
 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(-)

Bleep bloop.  Greetings Ben Pfaff, I am a robot and I have tried out your patch.
Thanks for your contribution.

I encountered some error that I wasn't expecting.  See the details below.


checkpatch:
WARNING: Line is 80 characters long (recommended limit is 79)
#398 FILE: ovn-architecture.7.xml:2671:
    For connecting to ramp gateways, in addition to Geneve and STT, OVN supports

Lines checked: 527, Warnings: 1, Errors: 0


Please check this out.  If you feel there has been an error, please email aconole@redhat.com

Thanks,
0-day Robot

On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <blp@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@redhat.com>
> Signed-off-by: Ben Pfaff <blp@ovn.org>

Acked-by: Numan Siddique <numans@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@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>

On Sun, Mar 29, 2020 at 11:32:32PM +0530, Numan Siddique wrote:
> On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <blp@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@redhat.com>
> > Signed-off-by: Ben Pfaff <blp@ovn.org>
> 
> Acked-by: Numan Siddique <numans@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.

If you want to do them at the same time, you're welcome to add this as
the first patch of a series of your own.

On Mon, Mar 30, 2020 at 9:21 PM Ben Pfaff <blp@ovn.org> wrote:
>
> On Sun, Mar 29, 2020 at 11:32:32PM +0530, Numan Siddique wrote:
> > On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <blp@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@redhat.com>
> > > Signed-off-by: Ben Pfaff <blp@ovn.org>
> >
> > Acked-by: Numan Siddique <numans@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.
>
> If you want to do them at the same time, you're welcome to add this as
> the first patch of a series of your own.

Sure. I'll try to get the patch in a couple of days. I'll let you know
in case I cannot
submit soon, in which case you can apply this patch.

Thanks
Numan'

> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>

On Tue, Mar 31, 2020 at 12:31:41AM +0530, Numan Siddique wrote:
> On Mon, Mar 30, 2020 at 9:21 PM Ben Pfaff <blp@ovn.org> wrote:
> >
> > On Sun, Mar 29, 2020 at 11:32:32PM +0530, Numan Siddique wrote:
> > > On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <blp@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@redhat.com>
> > > > Signed-off-by: Ben Pfaff <blp@ovn.org>
> > >
> > > Acked-by: Numan Siddique <numans@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.
> >
> > If you want to do them at the same time, you're welcome to add this as
> > the first patch of a series of your own.
> 
> Sure. I'll try to get the patch in a couple of days. I'll let you know
> in case I cannot
> submit soon, in which case you can apply this patch.

Perfect!

On Tue, Mar 31, 2020 at 1:39 AM Ben Pfaff <blp@ovn.org> wrote:
>
> On Tue, Mar 31, 2020 at 12:31:41AM +0530, Numan Siddique wrote:
> > On Mon, Mar 30, 2020 at 9:21 PM Ben Pfaff <blp@ovn.org> wrote:
> > >
> > > On Sun, Mar 29, 2020 at 11:32:32PM +0530, Numan Siddique wrote:
> > > > On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <blp@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@redhat.com>
> > > > > Signed-off-by: Ben Pfaff <blp@ovn.org>
> > > >
> > > > Acked-by: Numan Siddique <numans@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.
> > >
> > > If you want to do them at the same time, you're welcome to add this as
> > > the first patch of a series of your own.
> >
> > Sure. I'll try to get the patch in a couple of days. I'll let you know
> > in case I cannot
> > submit soon, in which case you can apply this patch.
>
> Perfect!

I've submitted the patch series here -
https://patchwork.ozlabs.org/project/openvswitch/list/?series=167889

I haven't worked on ovn-controller-vtep earlier. So I didn't try to
change or rename the internal data structures
too much. I just changed a few. Hope that's fine.

Thanks
Numan


> _______________________________________________
> dev mailing list
> dev@openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>