> We cannot make the assumption that the VNIC will always only expose > DL_ETHER MACs regardless of the type of the underlying device. > Today VNICs support only DL_ETHER at the bottom, and expose DL_ETHER > MACs on top. Some MAC types might have different requirements for > virtualization, or might not even support virtualization.
Agreed. > WIFI is an interesting example in that we can chose to expose a pure > DL_ETHER or a DL_WIFI/DL_ETHER MAC. However we cannot assume that > this will be always possible for all device types. Yep. Which is why I'm uncomfortable with the direction David is outlining. Even for WiFi, it's preferable to use DL_WIFI so that tools making use of the VNIC can be as fully-featured as possible (e.g., I can see actual WiFi frames with Wireshark), and so that we we're not wasting cycles swapping back and forth between frame formats. > > How much work would be involved in option (2)? Also, how large is the set > > > > of "all VNIC mac clients" that would need to "cook as required"? > > I think David meant the same cooking which is already done by the MAC > clients on top of a DL_WIFI MAC. If the VNIC on top of such a device > exposes the same type of MAC, then the clients of that VNIC would > have to perform the same operations as they do today when using the > device directly. Right, which should make this a non-issue since existing MAC clients can already handle native DL_WIFI links. So, in other words, I'm questioning the original design decision to translate DL_WIFI to DL_ETHER for VNICs -- while expedient, it doesn't allow VNICs to be as flexible and extensible as we'd want. -- meem
