Hi Anoop, Yes, you are right. Since a VAP accesses a single VNI, that does imply there would be a TSI per VAP, which does not correspond well to a VNIC. This is what Pat was saying also. I was hoping for the TSI to be more analogous to a VNIC since the VNIC goes up/down/migrates at one time and all the VNs it may connect to must follow that state. The Hypervisor-to-NVE protocol can be more optimized if that fact can be taken advantage of.
- Larry From: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Tuesday, April 16, 2013 5:32 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>> Cc: David Black <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Reith, Lothar" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes Hi Larry, That's how I would think about it as well. The part about 1:1 correspondence with vNICs/NICs tends to break down when we think of the case of a NIC or vNIC with multiple VLANs on it, each of which in turn, maps to a different VAP. So in this case, each of those VLANs on the NIC would correspond to a different TSI, right? Anoop On Tue, Apr 16, 2013 at 4:57 PM, Larry Kreeger (kreeger) <[email protected]<mailto:[email protected]>> wrote: Hi Anoop, I definitely see a TSI as belonging to a single tenant, since it is an interface on a single tenant's system (Tenant System). My assumption is that each TSI is associated with only one NVE, so that there is a one to one correspondence between a TSI and a VAP on the NVE. It is what is connected to the bottom lines in figure 4 of http://tools.ietf.org/html/draft-ietf-nvo3-framework-02 - Larry From: Anoop Ghanwani <[email protected]<mailto:[email protected]>> Date: Tuesday, April 16, 2013 4:47 PM To: David Black <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Reith, Lothar" <[email protected]<mailto:[email protected]>> Subject: Re: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes When I think of TSI, I think of something different than a vNIC (or, or in the case of non-virtualized systems, a NIC). Of course, it's possible to create an implementation where a TSI is always a vNIC (or NIC), but I don't think it is always limited to that. It might help to clarify the following properties of a TSI: - Can a TSI be associated with multiple NVEs? - Does a TSI carry traffic from only one tenant or multiple tenants? Anoop On Tue, Apr 16, 2013 at 3:32 PM, Black, David <[email protected]<mailto:[email protected]>> wrote: I think this may reflect some confusion around possible meanings of “interface”. I believe that the notion of “interface” that is desired here corresponds to a vNIC, not a bonded set of vNICs (and likewise to a NIC, not a bonded set of NICs). If that clarification is clear, I think TSI would be a reasonable term. Thanks, --David From:[email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Reith, Lothar Sent: Monday, April 15, 2013 7:18 AM To: Qin Wu; Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Subject: Re: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes I believe that it is not possible to replace the term vNIC with “TSI”, because multiple vNICs may form a single interface. AFAIK it is common practice to use vNIC bonding (LAG) for high availability, where two vNICs of one VM are associated with different physical NICs of the virtualization host running the VMs. Creating a LAG of these 2 vNICs ( NIC-Bonding) creates a single Interface of the VM which survives the outage of one of the both physical NICs. Lothar Von:[email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] Im Auftrag von Qin Wu Gesendet: Montag, 15. April 2013 09:17 An: Larry Kreeger (kreeger); [email protected]<mailto:[email protected]> Betreff: [nvo3] 答复: 答复: 答复: NVO3 Terminology changes >>I believe one tenant system can host multiple VMs, each VM may have multiple >>vNIC adapters that it uses to communicate with both the virtual and physical >>networks. >LK> A VM is one example of a tenant system…so it would not host VMs. You may >be thinking of "End Device". >[Qin]: Not sure about that, the definition of “Tenant system” in Framework >said: “ > Tenant System: A physical or virtual system that can play the role > of a host, or a forwarding element such as a router, switch, > firewall, etc. It belongs to a single tenant and connects to one or > more VNs of that tenant. ” >So tenant system can be a host and host one or multiple VMs on it. What am I >missing? >LK2> I think that you are assuming that "host" is synonymous with >"Hypervisor". In the definition above, I believe the term host relates to the >more traditional definition of an internet host such as in RFC 1122. [Qin]: So “Host” in the definition of tenant system seems misleading since we two have different interpretation to it. I agree Hypersor or Server or Server blade can host multiple VMs, however in the framework document, it also said, a host can be server or server blade in the definition of End device. LK3> Only servers or server blades that are running hypervisors can host multiple VMs. When we mean hypervisor we must say hypervisor (what form factor of server it is running on is irrelevant). All hypervisors run on servers, [Qin]: Yes. >but all servers are not running hypervisor software. [Qin]: Are you saying that not all server are running hypervisor software? If yes, I agree. If not, would you like to clarify a little bit? Suppose one tenant A have 2 VMs resided in the server1 or hypervisor1. Tenant B have 3 VMs resided in the server 1. Can we say each VM belonging to the same tenant is a tenant system LK3> Yes or multiple VMs of each tenant sharing the same Server belong to the same single tenant system? i.e., Tenant System A corresponding to Tenant A contains 2 VMs. Tenant System B corresponding to Tenant B contains 3 VMs. LK3> No, that would be a really bad idea IMO. The fact that two VMs happen to be running on the same server hardware is an ephemeral thing. From one moment to the next a VM may migrate to a different server where it becomes separated from the other VMs. Furthermore, I see no advantage in defining a Tenant System to be a grouping of VMs from a networking perspective since the thing that connects multiple VMs together is the network. [Qin]: Good point, I fully agree with you. Here is the update to http://www.ietf.org/internet-drafts/draft-wu-nvo3-nve2nve-03.txt, (NVO3 control plane requirement mostly for NVE to NV Authority/Controller interface) which clears terminology confusing based on our discussion. _______________________________________________ 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
