Dimitri, There are much (much) more applications/Guest OSs being deployed than switches/routers. It is hard for any data centers to throw away all their deployed servers/hypervisors in order to deploy new protocols coming from IETF. As you said that there are issues associated with IEEE802.1Qbg, how do you guarantee that new protocols coming out won't have any issues?
ARP/ND may not be dependable, but most Guest OSs (except very small percentage of Non-IP applications) do send them out. Linda > -----Original Message----- > From: Stiliadis, Dimitrios (Dimitri) [mailto:dimitri.stiliadis@alcatel- > lucent.com] > Sent: Tuesday, June 26, 2012 6:21 PM > To: Linda Dunbar; [email protected]; [email protected] > Cc: [email protected] > Subject: RE: [nvo3] Softswitches > > > > > > > If the NVE is on a ToR, then there is a need for an attach/detach > > > protocol method hypervisors and ToRs. > > > > > > > > > [Linda] Does it assume that hypervisors will need to add this new > > attach/detach function? > > There are different implementations possible for this. It could be > hypervisor driven or orchestration driven. My understanding is that > this > can be done today in all current hypervisors, although by using > different > methods (thus the need for a standard). > > > > > IEEE802.1Qbg defines a Virtual Interface Discovery Protocol (VDP) > which > > require Hypervisors to send Port Profile upon a new VM is added. > However, the > > This is one possible approach, but not the only one. It hasn't been > adopted by several hypervisor vendors for various reasons. > > > challenge is that Data Center operators may not be able to dictate > what > > servers/hypervisors being deployed in their data centers. > > > > If you can't dictate any changes to deployed hypervisors, "ARP/ND" > might be > > able to be used as a way to announce the attachment, and timeout to > declare > > the "detachment". > > I don't believe there is enough information in ARP to do this > attachment in > a multi-tenant environment. Who send the ARP and why should I trust > them. > > Dimitri > > > > > > > My two cents. > > > > Linda Dunbar > > > > NVE-2-oracle and oracle-2-rest_of_the_network I highly agree. But > I > > > am > > > > not sure if one size will fit all there. > > > > > > I think that David has a valid point trying to separate the two and > we > > > need both. > > > > > > Dimitri > > > > > > > > R. > > > > > > > > >> -----Original Message----- > > > > >> From: [email protected] [mailto:[email protected]] On > > > Behalf Of > > > > Robert > > > > >> Raszuk > > > > >> Sent: Tuesday, June 26, 2012 3:48 PM > > > > >> To: Black, David > > > > >> Cc: [email protected] > > > > >> Subject: Re: [nvo3] Softswitches > > > > >> > > > > >> Hi David, > > > > >> > > > > >> Honestly I think we are getting more into implementation then > > > > >> standardization debate. > > > > >> > > > > >> What I call a softswitch can be either part of the linux > kernel > > > entirely > > > > >> as a loadable module, can be partially in the kernel and > partially > > > in > > > > >> the user space or if you follow NETMAP's direct memory mapping > > > from > > > > >> interface to user space could sit completely there. > > > > >> > > > > >> Examples of softswitches which I am experimenting with is as > you > > > said > > > > >> one from VMWare, the other most popular is OVS, there is LINK > > > released > > > > >> recently and there is at least few more in the works which > would > > > be > > > > >> partially sitting in the end-system kernel or the kernel and > user > > > space. > > > > >> > > > > >> At least this is what I meant by using the term "embedded". > > > > >> > > > > >> The main point I think is that the L2/L3 > virtualization/separation > > > will > > > > >> be happening in all of the above cases which share one very > > > important > > > > >> common characteristic - thay are all residing on the end host. > > > > >> > > > > >> Best regards, > > > > >> R. > > > > > > > > > > > > _______________________________________________ > > > > 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
