Comment 5 for bug 1529863

As Chaoyi mentioned, it's more reasonable to make use of VXLAN functionalities.

Key words:
 - multicast group
 - unicast group
 - VNID

Here is scenario:

Some system, let's say system-A sends out an ARP request for some IP on its L2 VXLAN network.

VTEP1 receives this ARP request. If it does not have a mapping for some IP, VTEP1 encapsulates this ARP request in an ip multicast packet and forwards it to the VXLAN multicast group.

This multicast packet has ip address of VTEP1 as the source ip and the VXLAN multicast group address as destination ip address.

This multicast packet is distributed to all members in the tree. VTEP2 and VTEP3 receive the encapsulated multicast packet because they joined the VXLAN multicast group.

And this packet is de-encapsulated to check its VNID in the VXLAN header. If it matches their configured VXLAN segment VNID, they forward the ARP request to their local VXLAN network.

They also learn the ip address of VTEP1 from the outer ip address header and inspect the packet to lean the mac address of system-A, and placing this mapping in the local table.

Targeted system, let's say system-B receives the ARP request forwarded by VTEP2 then responds with its own mac address, and learns ip, mac mapping.

VTEP2 receives the ARP reply of system-B with ip, mac mapping. It can use the unicast tunnel to forward the ARP reply back to VTEP1.

Now in the encapsulated unicast packet, the source ip address is VTEP2's and the destination ip address is VTEP1's.

VTEP1 receives the encapsulated ARP reply from VTEP2, then de-encapsulates and forwards the ARP reply to system-A. And it learns ip address of VTEP2.

Any comments would be appreciated.