Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of adding explicit tunnel key

[Darrell Ball]

", node->name,
+tunnel_key[0] = '\0';
+if (ploc_cfg->tunnel_key) {
+snprintf(_key[0], 10, " %d",
+ (uint32_t)(*ploc_cfg->tunnel_key));
+}
+if (ploc_cfg->tunnel_level) {
+snprintf(tunnel_level, 10, " %s", ploc_cfg->tunnel_level);
+} else {
+tunnel_level[0] = '\0';
+}
+entry = xasprintf("  %s -> %s/%s%s%s", node->name,
   ploc_cfg->encapsulation_type,
   ploc_cfg->dst_ip,
-  tunnel_key );
+  tunnel_key,
+ tunnel_level);
 svec_add_nocopy(_macs, entry);
 }
 ds_put_format(>output, "ucast-mac-%s\n", local ? "local" :
"remote");
@@ -2093,13 +2121,22 @@ list_macs(struct ctl_context *ctx, bool local)
 char *entry;

 LIST_FOR_EACH (ploc, locators_node, _mac->locators) {
-tunnel_key[0] = 0;
-if (ploc->ploc_cfg->tunnel_key)
-snprintf(tunnel_key,8,"
[%d]",(uint32_t)(*ploc->ploc_cfg->tunnel_key));
-entry = xasprintf("  %s -> %s/%s%s", node->name,
+tunnel_key[0] = '\0';
+if (ploc->ploc_cfg->tunnel_key) {
+snprintf(tunnel_key, 10, " %d",
+ (uint32_t)(*ploc->ploc_cfg->tunnel_key));
+}
+if (ploc->ploc_cfg->tunnel_level) {
+snprintf(tunnel_level, 10, " %s",
+ ploc->ploc_cfg->tunnel_level);
+} else {
+tunnel_level[0] = '\0';
+}
+entry = xasprintf("  %s -> %s/%s%s%s", node->name,
   ploc->ploc_cfg->encapsulation_type,
   ploc->ploc_cfg->dst_ip,
-  tunnel_key);
+  tunnel_key,
+ tunnel_level);
 svec_add_nocopy(_macs, entry);
 }
 }
@@ -2556,11 +2593,11 @@ static const struct ctl_command_syntax
vtep_commands[] = {
 {"lr-exists", 1, 1, NULL, pre_get_info, cmd_lr_exists, NULL, "", RO},

 /* MAC binding commands. */
-{"add-ucast-local", 3, 5, NULL, pre_get_info, cmd_add_ucast_local,
NULL,
+{"add-ucast-local", 3, 6, NULL, pre_get_info, cmd_add_ucast_local,
NULL,
  "", RW},
 {"del-ucast-local", 2, 2, NULL, pre_get_info, cmd_del_ucast_local,
NULL,
  "", RW},
-{"add-mcast-local", 3, 5, NULL, pre_get_info, cmd_add_mcast_local,
NULL,
+{"add-mcast-local", 3, 6, NULL, pre_get_info, cmd_add_mcast_local,
NULL,
  "", RW},
 {"del-mcast-local", 3, 4, NULL, pre_get_info, cmd_del_mcast_local,
NULL,
  "", RW},
@@ -2568,11 +2605,11 @@ static const struct ctl_command_syntax
vtep_commands[] = {
  "", RO},
 {"list-local-macs", 1, 1, NULL, pre_get_info, cmd_list_local_macs,
NULL,
  "", RO},
-{"add-ucast-remote", 3, 5, NULL, pre_get_info, cmd_add_ucast_remote,
NULL,
+{"add-ucast-remote", 3, 6, NULL, pre_get_info, cmd_add_ucast_remote,
NULL,
  "", RW},
 {"del-ucast-remote", 2, 2, NULL, pre_get_info, cmd_del_ucast_remote,
NULL,
  "", RW},
-{"add-mcast-remote", 3, 5, NULL, pre_get_info, cmd_add_mcast_remote,
NULL,
+{"add-mcast-remote", 3, 6, NULL, pre_get_info, cmd_add_mcast_remote,
NULL,
  "", RW},
 {"del-mcast-remote", 3, 4, NULL, pre_get_info, cmd_del_mcast_remote,
NULL,
  "", RW},
diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
index 3a24318..35c3fd2 100644
--- a/vtep/vtep.ovsschema
+++ b/vtep/vtep.ovsschema
@@ -1,6 +1,6 @@
 {
   "name": "hardware_vtep",
-  "cksum": "353943336 11434",
+  "cksum": "2728111540 11603",
   "tables": {
 "Global": {
   "columns": {
@@ -209,7 +209,12 @@
   "type": "string"}},
   "mutable": false},
 "dst_ip": {"type": "string", "mutable": false},
-"tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}}},
+"tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}},
+"tunnel_level": {
+  "type": {
+   "key": {
+"enum": ["set", ["level0", "level1&

Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of adding explicit tunnel key

[Itamar Ofek]

Darrell,


To aviod lengthy  response, i'll address the issues directly.


The code in ovs-vtep should not be Neutron L2 border gateway specific.
Please remove references to so-called relay and mesh ports.

The relay vteps are a second level of hierachy of vteps - I have more
detail

 --agreed

Do not link per tunnel tunnel keys to Neutron L2 border gateway relay vteps
in generic code, such as ovs-vtep.


--agreed.


Regarding vtep.ovsschema:


diff --git a/vtep/vtep.ovsschema b/vtep/vtep.ovsschema
index 3a24318..f41568f 100644
--- a/vtep/vtep.ovsschema
+++ b/vtep/vtep.ovsschema
@@ -1,6 +1,6 @@
 {
   "name": "hardware_vtep",
-  "cksum": "353943336 11434",
+  "cksum": "3167636278 11608",
   "tables": {
 "Global": {
   "columns": {
@@ -209,7 +209,12 @@
   "type": "string"}},
   "mutable": false},
 "dst_ip": {"type": "string", "mutable": false},
-"tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}}},
+"tunnel_key": {"type": {"key": "integer", "min": 0, "max": 1}},
+"tunnel_level": {
+  "type": {
+"key": {
+  "enum": ["set", ["level0", "level1"]],
+  "type": "string"},"min": 0, "max": 1}}},
   "indexes": [["encapsulation_type", "dst_ip", "tunnel_key"]]},
 "ACL_entry": {
   "columns": {


I have no issues with this: just  two notes the tunne_level should default to 
"level0"

and vtep-ctl should be changed accordingly.

-- I can suggest a patch for it.


In order to make sure the handling in ovs-vtep satisfies the l2gw I'd prefers 
having your suggested patch

and run tests with it applied.


Regards


Itamar


From: dev <dev-boun...@openvswitch.org> on behalf of Darrell Ball 
<dlu...@gmail.com>
Sent: Saturday, August 13, 2016 4:05:07 AM
To: itamaro
Cc: ovs dev
Subject: Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of 
adding explicit tunnel key

I tried simulating your use case since there is no real test case
at the moment and found a missed check in my suggested incremental
patch.

I added the additional 2 lines
+if (tunnel_scope_key):
+tunnel_key = tunnel_scope_key

in the following context
+old_tunnel_ips = set(self.tunnels.keys())
+tunnel_ips = set(tunnels.keys())
+for tunnel_ip in tunnel_ips.difference(old_tunnel_ips):
+tunnel_scope_key = tunnels[tunnel_ip]
+if (tunnel_scope_key):
+tunnel_key = tunnel_scope_key
+self.add_tunnel(tunnel_ip, tunnel_key, tunnel_scope_key)





On Thu, Aug 11, 2016 at 2:12 PM, Darrell Ball <dlu...@gmail.com> wrote:

> I have various comments; I focused on the big picture mainly and
> did not review most details except ovs-vtep and one or two selected
> spots elsewhere, pending agreement on the big picture.
>
> Some comments are the same as I made in the first patch.
>
> Your patch did not apply cleanly due to previous change in
> vtep-ctl.c includes, I fixed it locally - please check.
>
>
> On Sun, Jul 24, 2016 at 5:01 AM, itamaro <itamar.o...@gmail.com> wrote:
>
>> From: itamaro <itamar.o...@gmail.com>
>>
>> This patch adds support for handeling a per-tunnel tunnel key in the
>> ovs-vtep and vtep-ctl to support the usage of neutron L2GW as an
>> inter-cloud gateway.
>>
>> The Neutron spec is available here:
>> https://review.openstack.org/#/c/270786/
>>
>> The aim of this patch is to support the usage of hardware vtep switch as
>> an inter-cloud gateway, which is used to connect two separated l2
>> broadcast
>> domains. This document will also explain the logic behind the addition of
>> the
>> new per-tunnel tunnel-key in the hardware_vtep schema.
>>
>> The introduction of the relay tunnel, does not change the current logic of
>> hardware_vtep, it does however introduce new logic related to iner-cloud
>> connectivity.
>>
>>
>> Network layout
>> ==
>>
>> virtual network 1 shared  network virtual
>> network 2
>> ++
>> ++
>> |Compute Host|   VNI=1VNI=2
>> |Compute Host|
>> |   +--+ <-++--->
>>  +--+

Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of adding explicit tunnel key

[Darrell Ball]

I tried simulating your use case since there is no real test case
at the moment and found a missed check in my suggested incremental
patch.

I added the additional 2 lines
+if (tunnel_scope_key):
+tunnel_key = tunnel_scope_key

in the following context
+old_tunnel_ips = set(self.tunnels.keys())
+tunnel_ips = set(tunnels.keys())
+for tunnel_ip in tunnel_ips.difference(old_tunnel_ips):
+tunnel_scope_key = tunnels[tunnel_ip]
+if (tunnel_scope_key):
+tunnel_key = tunnel_scope_key
+self.add_tunnel(tunnel_ip, tunnel_key, tunnel_scope_key)





On Thu, Aug 11, 2016 at 2:12 PM, Darrell Ball  wrote:

> I have various comments; I focused on the big picture mainly and
> did not review most details except ovs-vtep and one or two selected
> spots elsewhere, pending agreement on the big picture.
>
> Some comments are the same as I made in the first patch.
>
> Your patch did not apply cleanly due to previous change in
> vtep-ctl.c includes, I fixed it locally - please check.
>
>
> On Sun, Jul 24, 2016 at 5:01 AM, itamaro  wrote:
>
>> From: itamaro 
>>
>> This patch adds support for handeling a per-tunnel tunnel key in the
>> ovs-vtep and vtep-ctl to support the usage of neutron L2GW as an
>> inter-cloud gateway.
>>
>> The Neutron spec is available here:
>> https://review.openstack.org/#/c/270786/
>>
>> The aim of this patch is to support the usage of hardware vtep switch as
>> an inter-cloud gateway, which is used to connect two separated l2
>> broadcast
>> domains. This document will also explain the logic behind the addition of
>> the
>> new per-tunnel tunnel-key in the hardware_vtep schema.
>>
>> The introduction of the relay tunnel, does not change the current logic of
>> hardware_vtep, it does however introduce new logic related to iner-cloud
>> connectivity.
>>
>>
>> Network layout
>> ==
>>
>> virtual network 1 shared  network virtual
>> network 2
>> ++
>> ++
>> |Compute Host|   VNI=1VNI=2
>> |Compute Host|
>> |   +--+ <-++--->
>>  +--+ |
>> |   |vm| | ||   |
>>  |vm| |
>> |   +--+ | |   L3 network   |   |
>>  +--+ |
>> +---^+ ||
>>  +-^--+
>> |  +---v+  X +--v-+
>>  |
>> |  +---> hardware_vtep  |  X | hardware_vtep  |
>>  |
>> | VNI=1|   | logical switch |  X | logical switch
>> <-+ |
>> |  |   | (tunnel_key 1) |==<<==X=>>==| (tunnel_key 2) |
>>  |VNI=2|
>> |  |   |   +-+ +-+  |  X |   +-+  +-+ |
>>  | |
>> |  |   |   |-| |-|  |  X |   |-|  |-| |
>>  | |
>> +---v--v-+ ++  X ++
>>  | |
>> |Compute Host| vlan2|   |vlan5   vlan9||vlan21
>> | |
>> |   +--+ |  |   |relay vxlan  ||
>> +---v-v--+
>> |   |vm| |  |   |  VNI=100||
>> |Compute Host|
>> |   +--+ |  |   | |||
>>  +--+ |
>> +++-v-+   +-v-+ +-v-++-v-+  |
>>  |vm| |
>>   |   |   |   | |   ||   |  |
>>  +--+ |
>>   |   |   |   | |   ||   |
>> ++
>>   +---+   +---+ +---++---+
>> Bare metal elements Bare metal elements
>>
>> Logical switch
>> ===
>> In a cloud architecture, there is sometimes need to connect virtual
>> machines
>> and physical machines to the same L2 broadcast domain.
>> A logical switch is an entity representing an l2 virtual overlay network,
>> identified by a shared tunnel key. This tunnel key (VxLAN VNI) is shared
>> among
>> all overlay virtual tunnel endpoints (VTEP) of the switch.
>> The logical switch binds physical ports with either identical or different
>> "VLAN" tags to the "VxLAN overlay" network.
>>
>> In a multi-cloud architecture, it may be useful to establish a cross-cloud
>> l2 broadcast domain. The extended hardware vtep uses a relay l2 tunnel,
>> which is a tunnel with an explicit tunnel-key property. The tunnel-key
>> propery
>> is used to map each overlay network (logical switch tunnel-key) in each
>> cloud to
>> the tunnel-key of the relay tunnel.
>>
>> The mapping to a remote logical switch is done by defining the same
>> tunnel key
>> in both ends of the the relay tunnel. This tunnel key (VxLAN VNI) is a
>> property of the relay tunnel itself.
>>
>> To 

Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of adding explicit tunnel key

[Darrell Ball]

I have various comments; I focused on the big picture mainly and
did not review most details except ovs-vtep and one or two selected
spots elsewhere, pending agreement on the big picture.

Some comments are the same as I made in the first patch.

Your patch did not apply cleanly due to previous change in
vtep-ctl.c includes, I fixed it locally - please check.


On Sun, Jul 24, 2016 at 5:01 AM, itamaro  wrote:

> From: itamaro 
>
> This patch adds support for handeling a per-tunnel tunnel key in the
> ovs-vtep and vtep-ctl to support the usage of neutron L2GW as an
> inter-cloud gateway.
>
> The Neutron spec is available here:
> https://review.openstack.org/#/c/270786/
>
> The aim of this patch is to support the usage of hardware vtep switch as
> an inter-cloud gateway, which is used to connect two separated l2 broadcast
> domains. This document will also explain the logic behind the addition of
> the
> new per-tunnel tunnel-key in the hardware_vtep schema.
>
> The introduction of the relay tunnel, does not change the current logic of
> hardware_vtep, it does however introduce new logic related to iner-cloud
> connectivity.
>
>
> Network layout
> ==
>
> virtual network 1 shared  network virtual
> network 2
> ++
> ++
> |Compute Host|   VNI=1VNI=2
> |Compute Host|
> |   +--+ <-++--->
>  +--+ |
> |   |vm| | ||   |
>  |vm| |
> |   +--+ | |   L3 network   |   |
>  +--+ |
> +---^+ ||
>  +-^--+
> |  +---v+  X +--v-+
>|
> |  +---> hardware_vtep  |  X | hardware_vtep  |
>|
> | VNI=1|   | logical switch |  X | logical switch <-+
>|
> |  |   | (tunnel_key 1) |==<<==X=>>==| (tunnel_key 2) |
>  |VNI=2|
> |  |   |   +-+ +-+  |  X |   +-+  +-+ | |
>|
> |  |   |   |-| |-|  |  X |   |-|  |-| | |
>|
> +---v--v-+ ++  X ++ |
>|
> |Compute Host| vlan2|   |vlan5   vlan9||vlan21  |
>|
> |   +--+ |  |   |relay vxlan  ||
> +---v-v--+
> |   |vm| |  |   |  VNI=100||
> |Compute Host|
> |   +--+ |  |   | |||
>  +--+ |
> +++-v-+   +-v-+ +-v-++-v-+  |
>  |vm| |
>   |   |   |   | |   ||   |  |
>  +--+ |
>   |   |   |   | |   ||   |
> ++
>   +---+   +---+ +---++---+
> Bare metal elements Bare metal elements
>
> Logical switch
> ===
> In a cloud architecture, there is sometimes need to connect virtual
> machines
> and physical machines to the same L2 broadcast domain.
> A logical switch is an entity representing an l2 virtual overlay network,
> identified by a shared tunnel key. This tunnel key (VxLAN VNI) is shared
> among
> all overlay virtual tunnel endpoints (VTEP) of the switch.
> The logical switch binds physical ports with either identical or different
> "VLAN" tags to the "VxLAN overlay" network.
>
> In a multi-cloud architecture, it may be useful to establish a cross-cloud
> l2 broadcast domain. The extended hardware vtep uses a relay l2 tunnel,
> which is a tunnel with an explicit tunnel-key property. The tunnel-key
> propery
> is used to map each overlay network (logical switch tunnel-key) in each
> cloud to
> the tunnel-key of the relay tunnel.
>
> The mapping to a remote logical switch is done by defining the same tunnel
> key
> in both ends of the the relay tunnel. This tunnel key (VxLAN VNI) is a
> property of the relay tunnel itself.
>
> To support the above tunnel behevior, a new kind of VTEP port is logic is
> introduced, defining two VTEP port groups. One group represents the
> existing
> VTEP ports of the local l2 overlay network, and another new group
> represents the
> individual l2 relay VTEPS.
>
> Multicast and Unknown unicast traffic
> =
> Currently Broadcast, Unknown unicast, and Multicast,"BUM" traffic to the
> overlay networks
> is handled by two replication modes:
>
>   - "source_node" mode: The packets originated from physical port
> are replicated on all the VTEPs ports pointed by unknown-dst, and
> flooded
> to all the physical bound ports.
>
>   - "service_node" mode: The packets originated from physical port are
> forwarded to only a selected single service node from the unknown-dst
> ports
> 

Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of adding explicit tunnel key

[Itamar Ofek]

Justin ,

What is your opinion?

Regards

Itamar

On Sun, Jul 24, 2016 at 3:01 PM, itamaro  wrote:

> From: itamaro 
>
> This patch adds support for handeling a per-tunnel tunnel key in the
> ovs-vtep and vtep-ctl to support the usage of neutron L2GW as an
> inter-cloud gateway.
>
> The Neutron spec is available here:
> https://review.openstack.org/#/c/270786/
>
> The aim of this patch is to support the usage of hardware vtep switch as
> an inter-cloud gateway, which is used to connect two separated l2 broadcast
> domains. This document will also explain the logic behind the addition of
> the
> new per-tunnel tunnel-key in the hardware_vtep schema.
>
> The introduction of the relay tunnel, does not change the current logic of
> hardware_vtep, it does however introduce new logic related to iner-cloud
> connectivity.
>
>
> Network layout
> ==
>
> virtual network 1 shared  network virtual
> network 2
> ++
> ++
> |Compute Host|   VNI=1VNI=2
> |Compute Host|
> |   +--+ <-++--->
>  +--+ |
> |   |vm| | ||   |
>  |vm| |
> |   +--+ | |   L3 network   |   |
>  +--+ |
> +---^+ ||
>  +-^--+
> |  +---v+  X +--v-+
>|
> |  +---> hardware_vtep  |  X | hardware_vtep  |
>|
> | VNI=1|   | logical switch |  X | logical switch <-+
>|
> |  |   | (tunnel_key 1) |==<<==X=>>==| (tunnel_key 2) |
>  |VNI=2|
> |  |   |   +-+ +-+  |  X |   +-+  +-+ | |
>|
> |  |   |   |-| |-|  |  X |   |-|  |-| | |
>|
> +---v--v-+ ++  X ++ |
>|
> |Compute Host| vlan2|   |vlan5   vlan9||vlan21  |
>|
> |   +--+ |  |   |relay vxlan  ||
> +---v-v--+
> |   |vm| |  |   |  VNI=100||
> |Compute Host|
> |   +--+ |  |   | |||
>  +--+ |
> +++-v-+   +-v-+ +-v-++-v-+  |
>  |vm| |
>   |   |   |   | |   ||   |  |
>  +--+ |
>   |   |   |   | |   ||   |
> ++
>   +---+   +---+ +---++---+
> Bare metal elements Bare metal elements
>
> Logical switch
> ===
> In a cloud architecture, there is sometimes need to connect virtual
> machines
> and physical machines to the same L2 broadcast domain.
> A logical switch is an entity representing an l2 virtual overlay network,
> identified by a shared tunnel key. This tunnel key (VxLAN VNI) is shared
> among
> all overlay virtual tunnel endpoints (VTEP) of the switch.
> The logical switch binds physical ports with either identical or different
> "VLAN" tags to the "VxLAN overlay" network.
>
> In a multi-cloud architecture, it may be useful to establish a cross-cloud
> l2 broadcast domain. The extended hardware vtep uses a relay l2 tunnel,
> which is a tunnel with an explicit tunnel-key property. The tunnel-key
> propery
> is used to map each overlay network (logical switch tunnel-key) in each
> cloud to
> the tunnel-key of the relay tunnel.
>
> The mapping to a remote logical switch is done by defining the same tunnel
> key
> in both ends of the the relay tunnel. This tunnel key (VxLAN VNI) is a
> property of the relay tunnel itself.
>
> To support the above tunnel behevior, a new kind of VTEP port is logic is
> introduced, defining two VTEP port groups. One group represents the
> existing
> VTEP ports of the local l2 overlay network, and another new group
> represents the
> individual l2 relay VTEPS.
>
> Multicast and Unknown unicast traffic
> =
> Currently Broadcast, Unknown unicast, and Multicast,"BUM" traffic to the
> overlay networks
> is handled by two replication modes:
>
>   - "source_node" mode: The packets originated from physical port
> are replicated on all the VTEPs ports pointed by unknown-dst, and
> flooded
> to all the physical bound ports.
>
>   - "service_node" mode: The packets originated from physical port are
> forwarded to only a selected single service node from the unknown-dst
> ports
> (the service node responsible for "BUM" propagation to the overlay
> network),
> and flooded to all the physical bound ports.
>
> In either of the replication modes BUM traffic originated from a VTEP port
> is
> flooded only to all physical ports.
>
> Considering the new l2-relay VTEPs ports group, relay 

Re: [ovs-dev] [PATCH V3] ovs-vtep: vtep-ctl and ovs-vtep support of adding explicit tunnel key

[Ben Pfaff]

Justin, are you the best person to review this (when you're back from
vacation)?

Thanks,

Ben.

On Sun, Jul 24, 2016 at 03:01:00PM +0300, itamaro wrote:
> From: itamaro 
> 
> This patch adds support for handeling a per-tunnel tunnel key in the
> ovs-vtep and vtep-ctl to support the usage of neutron L2GW as an
> inter-cloud gateway.
> 
> The Neutron spec is available here:
> https://review.openstack.org/#/c/270786/
> 
> The aim of this patch is to support the usage of hardware vtep switch as
> an inter-cloud gateway, which is used to connect two separated l2 broadcast
> domains. This document will also explain the logic behind the addition of the 
> new per-tunnel tunnel-key in the hardware_vtep schema.  
> 
> The introduction of the relay tunnel, does not change the current logic of 
> hardware_vtep, it does however introduce new logic related to iner-cloud
> connectivity.
> 
> 
> Network layout
> ==
> 
> virtual network 1 shared  network virtual network 
> 2 
> ++  
> ++
> |Compute Host|   VNI=1VNI=2 |Compute 
> Host|
> |   +--+ <-++--->   +--+  
>|
> |   |vm| | ||   |   |vm|  
>|
> |   +--+ | |   L3 network   |   |   +--+  
>|
> +---^+ ||   
> +-^--+
> |  +---v+  X +--v-+   
> |   
> |  +---> hardware_vtep  |  X | hardware_vtep  |   
> |   
> | VNI=1|   | logical switch |  X | logical switch <-+ 
> |   
> |  |   | (tunnel_key 1) |==<<==X=>>==| (tunnel_key 2) | 
> |VNI=2|   
> |  |   |   +-+ +-+  |  X |   +-+  +-+ | | 
> |   
> |  |   |   |-| |-|  |  X |   |-|  |-| | | 
> |   
> +---v--v-+ ++  X ++ | 
> |   
> |Compute Host| vlan2|   |vlan5   vlan9||vlan21  | 
> |   
> |   +--+ |  |   |relay vxlan  ||
> +---v-v--+
> |   |vm| |  |   |  VNI=100|||Compute 
> Host|
> |   +--+ |  |   | |||   +--+  
>|
> +++-v-+   +-v-+ +-v-++-v-+  |   |vm|  
>|
>   |   |   |   | |   ||   |  |   +--+  
>|
>   |   |   |   | |   ||   |  
> ++
>   +---+   +---+ +---++---+
> 
> Bare metal elements Bare metal elements
> 
> Logical switch
> ===
> In a cloud architecture, there is sometimes need to connect virtual machines
> and physical machines to the same L2 broadcast domain.
> A logical switch is an entity representing an l2 virtual overlay network,
> identified by a shared tunnel key. This tunnel key (VxLAN VNI) is shared among
> all overlay virtual tunnel endpoints (VTEP) of the switch.
> The logical switch binds physical ports with either identical or different
> "VLAN" tags to the "VxLAN overlay" network.
> 
> In a multi-cloud architecture, it may be useful to establish a cross-cloud 
> l2 broadcast domain. The extended hardware vtep uses a relay l2 tunnel,
> which is a tunnel with an explicit tunnel-key property. The tunnel-key 
> propery 
> is used to map each overlay network (logical switch tunnel-key) in each cloud 
> to
> the tunnel-key of the relay tunnel.
> 
> The mapping to a remote logical switch is done by defining the same tunnel key
> in both ends of the the relay tunnel. This tunnel key (VxLAN VNI) is a
> property of the relay tunnel itself.
> 
> To support the above tunnel behevior, a new kind of VTEP port is logic is
> introduced, defining two VTEP port groups. One group represents the existing
> VTEP ports of the local l2 overlay network, and another new group represents 
> the
> individual l2 relay VTEPS.
> 
> Multicast and Unknown unicast traffic
> =
> Currently Broadcast, Unknown unicast, and Multicast,"BUM" traffic to the 
> overlay networks
> is handled by two replication modes:
> 
>   - "source_node" mode: The packets originated from physical port
> are replicated on all the VTEPs ports pointed by unknown-dst, and flooded
> to all the physical bound ports.
> 
>   - "service_node" mode: The packets originated from physical port are
> forwarded to only a selected single service node from the unknown-dst 
> ports
> (the service node responsible for "BUM" propagation to the overlay 
> network),
> and flooded to all the