On Tue, Mar 24, 2020 at 5:15 AM Ben Pfaff <[email protected]> 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 <[email protected]> > Signed-off-by: Ben Pfaff <[email protected]>
Acked-by: Numan Siddique <[email protected]> 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 > [email protected] > https://mail.openvswitch.org/mailman/listinfo/ovs-dev > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
