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]>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]> > Date: Tuesday, April 16, 2013 4:47 PM > To: David Black <[email protected]> > Cc: "[email protected]" <[email protected]>, "Reith, Lothar" < > [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]> 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]] *On Behalf >> Of *Reith, Lothar >> *Sent:* Monday, April 15, 2013 7:18 AM >> *To:* Qin Wu; Larry Kreeger (kreeger); [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]] *Im Auftrag >> von *Qin Wu >> *Gesendet:* Montag, 15. April 2013 09:17 >> *An:* Larry Kreeger (kreeger); [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] >> https://www.ietf.org/mailman/listinfo/nvo3 >> >> >
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
