+1 with Dave Allen‘s definition I tend to oppose the view that the term “virtual” can degenerate into a meaning that also includes “physical”. This may confuse or make impossible a common understanding of the term “virtualization” in the contexts of compute, store and network. A common definition of “virtualization” could be along the lines that virtualization decouples a logical resource from a dedicated physical resource by introducing a virtualization layer running on the same or a different physical resource, such that now the virtualization layer provides the interfaces to the higher layers that previously the physical resource used to provide directly. With physical resource I mean a storage, compute or network resource. In case of storage, the storage in an X86 architecture server or PC gets emulated by some network attached storage, which may even be distributed over multiple locations or replicated. The architecture of the virtualization host does not have to be X86 based, however, the VMs architecture is.
In the case of network, I am intentionally silent, and would appreciate comment if the definition may fit or how it could be improved. Lothar Von: [email protected] [mailto:[email protected]] Im Auftrag von Eric Gray Gesendet: Mittwoch, 17. April 2013 21:24 An: David Allan I; Black, David Cc: [email protected] Betreff: Re: [nvo3] NVO3 Terminology changes And, of course, this is another (probably better) way to look at it. From: David Allan I Sent: Wednesday, April 17, 2013 11:52 AM To: Black, David; Eric Gray Cc: [email protected] Subject: RE: [nvo3] NVO3 Terminology changes Importance: High Hi Dave I have some sympathy with Eric's point but would suggest inverting the relationship to address your concern. The generic class is NIC, which may or may not be virtualizated....the virtual form being associated with VMs, and the generic class being associated with addressed end systems in general. I think moving away from NIC to produce some gratuitous new term is not doing us any favors... cheers Dave ________________________________ From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Black, David Sent: Wednesday, April 17, 2013 8:46 AM To: Eric Gray Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] NVO3 Terminology changes Eric, > In other words, a NIC can be said to be a non-tagging vNIC that supports only > one virtual (untagged) interface. I disagree. The term vNIC has become strongly associated with virtual machines, and I don’t believe that this term is generally understood to encompass physical NICs on physical servers or other systems - e.g., a middlebox, such as a firewall. > Also, can you clarify what it means to have distinct Virtual Local Area > Networks > (VLANs) that are not "connected to different virtual networks"? Sure, consider a virtual network providing L2 VLAN-tagged service, and configured so that any Ethernet frame arriving at the NVE is encapsulated to the same VNI, regardless of VLAN. The result is that the inner L2 Ethernet header beyond the NVE includes the unchanged VLAN tag. In this case, the virtual network instance (VNI) supports multiple VLANs end-to-end, and those VLANs have no interactions with the NVEs (the VLAN tag just passes through encap and decap). Thanks, --David From: Eric Gray [mailto:[email protected]] Sent: Wednesday, April 17, 2013 11:20 AM To: Black, David; Jon Hudson; Truman Boyes Cc: [email protected]<mailto:[email protected]> Subject: RE: [nvo3] NVO3 Terminology changes David, Not sure I agree with this. While the term "virtual" has become (through usage) a common term used to distinguish something (for example an interface, network, or private network) from the analog in reality �C it should actually be the case that virtual includes physical as a degenerate case. In other words, a NIC can be said to be a non-tagging vNIC that supports only one virtual (untagged) interface. Also, can you clarify what it means to have distinct Virtual Local Area Networks (VLANs) that are not "connected to different virtual networks"? -- Eric From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Black, David Sent: Wednesday, April 17, 2013 11:08 AM To: Jon Hudson; Truman Boyes Cc: [email protected]<mailto:[email protected]> Subject: Re: [nvo3] NVO3 Terminology changes OTOH, if the vNIC is an 802.1Q VLAN-tagged interface, and different VLANs are connected to different virtual networks (VNIs, Virtual Network Instances), then the tenant side interface that corresponds to the VAP on the NVE is the VLAN within the vNIC. At the other extreme, if the VNI is also 802.1Q tagged, and all the VLAN tags used by the vNIC are used with the same VNI, then the vNIC as a whole is what corresponds to the VAP. We still need a term other than vNIC, as use of that term excludes physical network interfaces from participation in virtual networks. Thanks, --David From: Jon Hudson [mailto:[email protected]] Sent: Wednesday, April 17, 2013 10:29 AM To: Truman Boyes Cc: John E Drake; [email protected]<mailto:[email protected]>; Reith, Lothar; Black, David; Anoop Ghanwani; Larry Kreeger (kreeger); Qin Wu Subject: Re: [nvo3] NVO3 Terminology changes It's a worthwhile point. While I think it's always better to design for "N" and not "2" I don't think I have ever seen more that two vNICs on a VM. For the primary reason that it's usually 1:1 app to VM (if you can run multiple apps in the OS, then just keep running Linux, move on and forge this whole virtualization fad) The only argument I can think of for running more than 2 is bandwidth, but vNICs are not NICs and can be bound to any speed interface the hypervisor is willing to support. So bandwidth is not a reason to bond 7 vNICs to a VM. So while designing for N is logical, worrying too much about more than 2 vNICs per VM isn't terrible realistic. And as you said many many customers just run one vNIC per VM. J On Apr 17, 2013, at 4:15 PM, Truman Boyes <[email protected]<mailto:[email protected]>> wrote: Hilarious. Btw, is this multiple vNIC scenario based on real world experience? I am scared of more than 1 vNIC in a large scale deployment due to complexities in routing at the host level and further upstream. There may be corner cases the require a different set of reachable vectors for a vm but there are many ways to provide that without more vNICs. Not completely opposed to the idea, but when I see scenarios discussing VMs with 5 vNICs I think the IETF may be off course here. There is a lot of rope, it's our choice to make a raft or a noose. Truman On Wednesday, April 17, 2013, John E Drake wrote: This thread reminds me of the lyrics to a Nicki Minaj song. Irrespectively Yours, John From: [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');> [mailto:[email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>] On Behalf Of Qin Wu Sent: Tuesday, April 16, 2013 7:15 PM To: Larry Kreeger (kreeger); Anoop Ghanwani; Black, David Cc: [email protected]<javascript:_e(%7b%7d,%20'cvml',%20'[email protected]');>; Reith, Lothar Subject: [nvo3] 答复: 答复: 答复: 答复: NVO3 Terminology changes Hi, Larry: Is relation between vNIC and TSI one to one or one to more? Let me interpret what you said below, (a)If a VM has only one vNIC, then vNIC that belongs to the VM will be dealt with as one tenant system. Each vNIC corresponds to one TSI. (b) If a VM has 5 vNICs and each vNIC is assigned with only one IP address, each vNIC that belongs to the same VM will be treated as one Tenant System. Each vNIC corresponds to one TSI. Then one VM have 5 Tenant system. Each Tenant System has one TSI. (c) If a VM has 5 vNICs and each vNIC is assigned with 2 IP addresses, each vNIC that belongs to the same VM will be treated as one Tenant system, each vNIC with each IP address corresponds to one TSI. Then one VM has 5 tenant system. Each Tenant system has 2 TSIs. That is to say if the relation between vNIC and TSi is one to more, then we can easy to guarantee that each TSI is associated with only one NVE. However if one VM is simply regarded as one tenant system and each vNIC with multiple IP addresses belonging to one VM is treated as only one TSI in (b)(c), take (c) as an example. when one vNIC is assigned with multiple IP addresses and connect to multiple VNs through multiple NVE, then one TSI has multiple IP addresses and will be associated with multiple NVEs. Here is two figure2, figure 1 shows one to one relation between vNIC and TSI, figure 2 shows one to more relation between vNIC and TSI. _______________________________________________ nvo3 mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/nvo3
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
