I had a few topics and questions I'd like to raise on this topic also. To give some concrete context for these thoughts, I am taking the perspective of someone in a cloud environment who is supporting (potentially) hostile customers/user-administrators that may not put effort to voluntarily play nice with each other. The topics below reflect questioning how much one would wish the virtual networks to mimic physical networks along a number of dimensions Performance: Should one virtual network's bursts affect the latency, bandwidth, and drops on other virtual networks when the virtual networks are sharing physical links, switches, servers, storage, etc.? Namespace: Which namespaces are fully-virtualized and hence avoid any possible numbering conflicts among virtual networks on shared hardware. Lots of possibilities here, for point of discussion here's one specific example: MAC: physical, shared numbering space among all virtual networks VLAN 12-bit queue: physical, shared numbering among all virtual networks VLAN 2nd 12-bit Q-inQ: virtual, extra namespace available within a virtual network IP: new namespace per virtual network TCP: new namespace per virtual network UDP: new namespace per virtual network iSCSI: new namespace per virtual network FCoE: new namespace per virtual network Administrative model: Should we be able to support firm restrictions on what a given virtual network administrator can see or modify about other virtual networks? In terms of acid tests, does the administrative model, in effect, mimic the act of given a customer/user a bunch of physical network hardware that they have full control over, while restricting them from configuring or probing someone else's physical hardware. - Robert On Nov 9, 2010, at 11:07 AM, Sunay Tripathi wrote: > So looking at the Acid tests so far and VN principles, it seems like > we need to tighten the isolation case a bit more. Specifically, just > putting a Virtual Output Queue (VoQ) per VN on each link to provide > isolation is not cutting it. The isolation (which translates > into per packet latency and B/W) needs to be on a VN fabric level > rather than on individual link level. Basically the VN should > mirror the non virtualized physical network of same capacity i.e. > a VN for 1Gbps on a 10Gbps network should see same or better > behavior than if it was on a physical 1Gbps switch fabric by > itself. This does need the network elements like switches and > routers to do more work. > > Robert, not sure if you are on the VNRG mailing list but this > would be a good place for some of the things we were discussing > related to what we are building. > > The other thing is related to management. A VN administrator > needs to be able to administer his resources and name space > independently. > > But the issue that is bogging us down is what is the non virtualized > part that ties entities to VN and allows the H/W to enforce the > virtualization - is it the MAC address? Is it the VLAN? The problem > with VLAN is that most hosts don't support Q-in-Q. Do people > have thoughts on this? > > Cheers, > Sunay > > > _______________________________________________ > vnrg mailing list > vnrg at irtf.org > https://www.irtf.org/mailman/listinfo/vnrg
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.