+1 It is no different than if a given app runs native or virtualised, both these models exist and NVO-3 networking will not differentiate either of them.
Alan -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of David Allan I Sent: April-24-13 12:10 PM To: Reith, Lothar; ramki Krishnan; Jon Hudson Cc: Thomas Narten; Pat Thaler; [email protected]; Qin Wu Subject: Re: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt The architecture should not care...No difference between a bare metal server, and any other non-NVO3 networking or storage appliance that needs to be included in the overall compute and networking mix...we just have fewer "v"s in the bare metal case... Cheers Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Reith, Lothar Sent: Wednesday, April 24, 2013 3:49 AM To: ramki Krishnan; Jon Hudson Cc: Thomas Narten; Pat Thaler; [email protected]; Qin Wu Subject: Re: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt I have not problem if the framework document explicitly states that bare metal servers without hypervisor are out of scope. Lothar -----Ursprüngliche Nachricht----- Von: ramki Krishnan [mailto:[email protected]] Gesendet: Mittwoch, 24. April 2013 08:01 An: Jon Hudson; Reith, Lothar Cc: Thomas Narten; Pat Thaler; [email protected]; Qin Wu Betreff: RE: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt Agree with Jon. >From my interaction with customers, one of the popular use cases for bare >metal servers is Analytics applications for e.g. Hadoop; the key reason is >that these applications keep the CPU busy all the time and hence there is no >benefit to virtualization. Thanks, Ramki -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jon Hudson Sent: Tuesday, April 23, 2013 8:40 PM To: Reith, Lothar Cc: Thomas Narten; Pat Thaler; [email protected]; Qin Wu Subject: Re: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt Actually I have customers that still virtualize an OS/App even when the result is a 1:1:1 relationship. Due to direct mapping advancements overhead from running on a hypervisor is very very small. Where the benefits of running an OS/App pair as a VM are many. For example 1.) Abstract an older OS like Windows NT that does not have drivers for current hardware. 2.) Ability to pause, clone, snapshot or rollback the VM. 3.) Ability to move the VM live from one hypervisor to another. Jon On Apr 22, 2013, at 12:36 AM, "Reith, Lothar" <[email protected]> wrote: > Hi Qin, > > I had read that a bare metal server is being used by people who do want to > eliminate the overhead introduced by the hypervisor to the performance of the > server. If the server runs only a single application - why introduce the > overhead of a hypervisor and suffer from the associated performance > degradation? > > Therefore I tend to disagree with the statement, that a bare metal server is > some kind of hypervisor. > > Lothar > > -----Ursprüngliche Nachricht----- > Von: Qin Wu [mailto:[email protected]] > Gesendet: Montag, 22. April 2013 03:59 > An: Reith, Lothar; Thomas Narten; Pat Thaler > Cc: [email protected] > Betreff: RE: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt > > Hi, Lothar: > Bare metal server is some kind of hypervisor. As I discussed with Larry on > the list before, usually hypervisor hosts multiple VMs. Each VM can be a > tenant system. So I think the case B doesn't stand. > > Regarding Case A and Case C, I think tenant system can be either physical > system or virtual system, as tenant system definition pointed out. > 1.If tenant system is physical system, this could be out of scope of > NVO3 since as Thomas mentioned, native connection to DC network is not > necessary to be in the scope of NOV3. I agree with this, since if > tenant system is physical system(e.g., physical network service > appliance, the tenant system doesn't need to be a VM) > > 2. If tenant system is virtual system, it has two categories: > Category (a) Tenant system plays host role Category (b) Tenant system > plays forwarding element role (I think it should be virtual forwarding > element, if the tenant system is a firewall, it should be virtual > firewall) > > Case A and Case C, in my understanding fall into these two categories. > > Regards! > -Qin > -----Original Message----- > From: Reith, Lothar [mailto:[email protected]] > Sent: Sunday, April 21, 2013 7:21 PM > To: Thomas Narten; Pat Thaler > Cc: [email protected]; Qin Wu > Subject: AW: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt > > Thomas, > > See below. I do not agree to the wording. > > And I suggest to change the definition of tenant system, which I identified > as being perhaps a root cause of confusion. > > Lothar > > -----Ursprüngliche Nachricht----- > Von: [email protected] [mailto:[email protected]] Im Auftrag > von Thomas Narten > Gesendet: Freitag, 19. April 2013 20:49 > An: Pat Thaler > Cc: [email protected]; Qin Wu > Betreff: Re: [nvo3] vNICs and pNics in draft-wu-nvo3-nve2nve-04.txt > > "Pat Thaler" <[email protected]> writes: > >> In addition to Thomas's point, we should not restrict the number of >> physical NICs that a tenant system can have. Some tenant systems will >> have more than one physical NIC. > > Agreed. > > Lothar: Disagree - Given the current definition of tenant system, one would > have to make a case differentiation throughout the document as follows: > > Case A: Tenant System is a VM > - In this case - which may be the most important one to many - above > statement is wrong, because then the tenant system has zero physical NICs. > > Case B: Tenant System is a bare metal server > - In this case above statement is true > > Case C: Tenant System is "according to current definition" a router or > firewall... > - in this case we start referring to router ports as NICs or pNICs, which may > further increase confusion. > >> We may describe some typical tenant systems as part of examining use >> cases, but NVO3 should define behavior in terms of the network >> interface, i.e. TSI, behavior and should not restrict tenant system >> architecture. > > Another way of looking at it is that the TSI is an attachement > point/interface to the TS. The point where the TSI attaches to the TS > has two sides. On the tenant facing side, it appears to be a NIC. It > looks like a NIC, behaves like a NIC, etc. On the side facing away > from the tenant (e.g., the hypervisor in the case of a virtualized > system) we call it a TSI. The TSI side will have attributes that are > specific to NVO3. > > Does that make sense? > > Thomas > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
