Re: Xend vnet support to be removed

[Mike Wray <mike.wray@hp.com>]

James Harper wrote:
> Based on the description from your documentation, it sounds like the
> guts of vnets could be done with 802.1q vlan trunking and bridging. No
> extra code required. I'm already doing this now, where each xen server
> has two physical interfaces (one for AoE, and one for domu network
> access). I can provide some more information on 802.1q vlan trunking if
> anyone is interested.
> 
> I'm basing all of my knowledge of vnets on a brief skim of the
> documentation in your email below, so feel free to enlighten me as to
> why they are different :)

In terms of abstract functionality they are very similar,
but there are important practical differences.
As far as I am aware, use of vlans requires that you have vlan-capable
switches in your network, and that you can configure them. Ordinary mortals
can't usually configure their network's vlan switches (if it has them).
Vnets don't require any assistance from the network,
and can be tunneled to remote subnets or through firewalls.
This is because vnets tunnel ethernet frames inside IP packets, which are
then routed normally, rather than using a modified ethernet frame like the
802.1q vlan header.

So a vnet can be created by anyone and its connectivity can span an
arbitrary piece of the IP network - not something you can do with vlans
It's also possible to run completely independent vnet infrastructures on the
same network simply by using different multicast addresses.
A new vnet can be dynamically created by configuring its endpoints, without
configuring anything in the network.

Vlan packets are limited to a 12-bit vlan id and have no support for
authentication or encryption. Vnets support 128-bit vnet ids and can
support authentication and encryption, currently using IPSEC.

Mike