Add a CNI for Windows

[rakelkar]

Creating a new issue to get feedback on whether it makes sense to add a Windows CNI in this repository vs a separate repo? Contrib guidelines ask for 3rd party plugins to live in their own repo - however one could possibly argue that a Windows plugin makes sense to round off CNI OS support? Looking for opinions.

WinCNI as it is implemented today is a single EXE that implements the CNI interface and uses the hcsshim GO wrapper to configure Windows HNS Networks and Endpoints (https://github.com/Microsoft/hcsshim).

[rosenhouse]

@rakelkar this is a good question. thinking more about this, in relation to #77 and #84 I have a couple questions:

1. how many Windows CNI plugins are there today? do you anticipate a large ecosystem (like there is today for linux CNI plugins)?
2. how much code will Windows CNI plugins share with Linux plugins? how much code will Windows CNI plugins share with each other?

[rakelkar]

How many Windows CNI plugins are there today:
The only CNI I am aware of is the Azure CNI. I have reached out to the Windows Kernel HNS - Host Networking Service folks to comment as well.

Do you anticipate a large ecosystem:
I think the number of plugins will be limited since their operations is dependent on Kernel support. It is possible in theory to write kernel drivers to emulate this stuff, but that would not be many (the Azure plugin is an example).

My assumption is that this repository has canonical plugins for the base cases and folks are free to create 3rd party plugins in their own repos. To this end I think it makes sense to have canonical plugins for windows. My PR proposes plugins that configure HNS for the two primary modes: host-gw and vxlan, and is built in collaboration with the Windows HNS team (who are onboard to help evolve this as HNS features evolve).

Code sharing with Linux plugins:
I don't expect them to share any code with Linux plugins that implement similar modes - however they obviously reuse CNI methods in general.

Code sharing between Windows plugins:
I do expect them to share code. My PR includes shared code under pkg/hns to provision/de-provision HNS endpoints. Other examples of shared code is features that are agnostic of network type such as runtime port mapping.

[JMesser81]

Cloudbase Solutions (@alexpilotti) and team are also developing a Windows CNI plugin for OVN/OVS. The Windows team will support win-l2bridge and win-overlay (vxlan) CNI plugins. These plugins can either be used directly or by Flannel for host-gateway and overlay modes respectively.

[astrieanna]

Should this issue be closed now that #193 is merged?

[rakelkar]

Resolved by #193