Now I’ve previosly blogged about some of the other networking component in AzureStack (Software Load Balancing) and Distributed Firewall which are essential components on how we can achive a software-defined network. Now both the dfW and SLB are just components that operate in the data plane, but would not be possible without a central component which lies in the control plane, namely the Network controller.
Now for those that haven’t heard about it yet, it is a new role in Windows Server 2016 which is in essence a centrally component to manage the infrastructure network. From an AzureStack perspective, when we go in and configure a Network Security Group or a load balancing IP address, or either by usingPowerShell scripts, or System Center Virtual Machine Manager (SCVMM) it programs network policy through the RESTful API exposed by the Microsoft Network Controller. The Network Controller then distributes this policy to each of the Hyper-V hosts using the OVSDB Protocol and a set of schemas to represent virtual networks, ACLs, user-defined routing, and other policy tothe virtual network.
Another critical piece of this SDDC is the new Software Defined Network (SDN) Stack which the Hyper-V Virtual Switch using the Azure Virtual Filtering Platform (VFP) Switch Extension, which is also controlled by the Networking Controller.
Now for those that have worked with VXLAN from VMware NSX for instnace knows that there are different modes UniCast/Hybrid/Multicast, Microsoft does it a bit different, when a Tenant VM wants to communicate with Tenant VM 2 on another hyper-V host for instance, it first needs to send an ARP request to the network to get ahold of the MAC address of that VM. The Network Controller Host Agent programs the VFP on the vSwitch to inject a direct respons to that ARP request with the MAC address of Tenant VM2, so the information comers directly from the Network Controller.
So when Tenant-VM1 wants to communicate with Tenant-VM2, a TCP request will go the vSwitch, the VFP mapping rule will be used to create a VXLAN header with the VNI of the network that both tenant-VM’s belong to. Then the packet will go across the physical wire to the other host, the VFP on the vSwitch will strip of the VXLAN header look at the inner ethernet frame and find the MAC of tenant-VM2 
NOTE: There is one thing you should know the VXLAN implementation of Windows Server 2016 it does not support interoperability with third party hardware VTEPs due to a difference in OVSDB schemas. They are using a custom OVSDB schema to convey additional policy information such as ACLs and service chaining which was not available in the initial hardware_VTEP schema. However, support for the core protocols (VXLAN, OVSDB) is in place in the platform to bring in support for hardware VTEPs in the future.
If you want to try this from System Center Virtual Machine Manager there is a deployment setup using SDN express here –> https://blogs.technet.microsoft.com/scvmm/2016/11/28/announcing-vmm-sdn-express-for-vmm-2016/ or you can look here as well –> https://github.com/Microsoft/SDN#sdn-rras-gateway