added clarification on transparent networking not working on Azure

virtualization/windowscontainers/container-networking/architecture.md

@@ -68,6 +68,7 @@ The Host Networking Service (HNS) and the Host Compute Service (HCS) work togeth
    * Encrypted container communication via IPsec.
    * HTTP proxy support for containers.  A preliminary PR for this can be tracked [here](https://github.com/Microsoft/hcsshim/pull/163).
    * Attaching endpoints to running Hyper-V containers (hot-add).
+   * Networking on virtualized Azure infrastructure via the transparent network driver.
 
  | Command        | Unsupported Option   |
  | ---------------|:--------------------:|

virtualization/windowscontainers/container-networking/network-drivers-topologies.md

@@ -19,16 +19,19 @@ In addition to leveraging the default 'nat' network created by Docker on Windows
   > Multiple NAT networks are supported if you have the Windows 10 Creators Update installed!
 
 - **transparent** – containers attached to a network created with the 'transparent' driver will be directly connected to the physical network through an *external* Hyper-V switch. IPs from the physical network can be assigned statically (requires user-specified ``--subnet`` option) or dynamically using an external DHCP server. 
+  > Note: Due to the below requirement, connecting your container hosts over a transparent network is not supported on Azure VMs.
+  
+  > Requires: When this mode is used in a virtualization scenario (container host is a VM) _MAC address spoofing is required_.
 
 - **overlay** - when the docker engine is running in [swarm mode](../manage-containers/swarm-mode.md), containers attached to an overlay network can communicate with other containers attached to the same network across multiple container hosts. Each overlay network that is created on a Swarm cluster is created with its own IP subnet, defined by a private IP prefix. The overlay network driver uses VXLAN encapsulation. **Can be used with Kubernetes when using suitable network control planes (Flannel or OVN).**
-  > Note: Make sure your environment satisfies these *required* [prerequisites](https://docs.docker.com/network/overlay/#operations-for-all-overlay-networks) for creating overlay networks.
+  > Requires: Make sure your environment satisfies these *required* [prerequisites](https://docs.docker.com/network/overlay/#operations-for-all-overlay-networks) for creating overlay networks.
 
-  > Note: Requires Windows Server 2016 with [KB4015217](https://support.microsoft.com/en-us/help/4015217/windows-10-update-kb4015217),  Windows 10 Creators Update, or a later release.
+  > Requires: Requires Windows Server 2016 with [KB4015217](https://support.microsoft.com/en-us/help/4015217/windows-10-update-kb4015217),  Windows 10 Creators Update, or a later release.
 
 - **l2bridge** - containers attached to a network created with the 'l2bridge' driver will be in the same IP subnet as the container host, and connected to the physical network through an *external* Hyper-V switch. The IP addresses must be assigned statically from the same prefix as the container host. All container endpoints on the host will have the same MAC address as the host due to Layer-2 address translation (MAC re-write) operation on ingress and egress.
-  > Note: When this mode is used in a virtualization scenario (container host is a VM) _MAC address spoofing is required_.
+  > Requires: When this mode is used in a virtualization scenario (container host is a VM) _MAC address spoofing is required_.
   
-  > Note: Requires Windows Server 2016, Windows 10 Creators Update, or a later release.
+  > Requires: Requires Windows Server 2016, Windows 10 Creators Update, or a later release.
 
 - **l2tunnel** - Similar to l2bridge, however _this driver should only be used in a Microsoft Cloud Stack_. Packets coming from a container are sent to the virtualization host where SDN policy is applied.