Yes, VEPA is targeting exactly this. It helps unifying the management of virtualized data center networks by simplifying the interface between a virtualized server and the data center network infrastructure. The introduction of embedded virtual switching within the hypervisor introduces visibiltiy and control issues as traditional network devices no longer process certain packet flows. VEPA addresses these challenges. We have also submitted patches to the Linux kernel to enable basic VEPA operation for the Linux bridge module: http://www.mail-archive.com/bridge at lists.linux-foundation.org/msg01248.html http://www.mail-archive.com/bridge at lists.linux-foundation.org/msg01249.html We also submitted VEPA patches for Xen/KVM virtualization layers. Let me know if you have any specific question, or if you are interested in anything particular around VEPA. Cheers, Anna > -----Original Message----- > From: hideki.okita.pf at hitachi.com [mailto:hideki.okita.pf at hitachi.com] > Sent: 31 July 2009 10:53 > To: Fischer, Anna > Cc: nvrg at listserv.gwdg.de > Subject: Re:[nvrg-bof] virtual network management information model > > Anna, > > > Thank you for the information about EVB and VEPA. > > We are interested in these active works around server > virtualization platforms since it would become > a configuration and management interface between > the data center network management system and a > server virtualization platform. > > > Regards, > > Hideki Okita > > > >I thought you might find this interesting too - related to unified > virtual network management within data centers and increased management > complexity introduced by traditional virtual switches: > > > >http://tech.groups.yahoo.com/group/evb/ > > > >An unofficial Edge Virtual Bridging ad hoc group that is working to > develop concepts and proposals related to Edge Virtual Bridging for > consideration by the IEEE 802.1 working group. The proposal(s) are > intended to address the following needs: (1) a simple aggregation > capability that could be integrated into new NICs to support PCI > virtual functions and PCIe IO virtualization devices, (2) to allow an > external bridge control of vNIC connectivity, and (3) to support the > creation of simplified, stand-alone network edge devices. The focus of > this group is primarily oriented at the Data Center environment. > > > >Most importantly the proposal of the VEPA standard: > >http://www.ieee802.org/1/files/public/docs2009/new-hudson- > vepa_seminar-20090514d.pdf > > > >A Virtual Ethernet Port Aggregator (VEPA) is a capability within a > physical end station that collaborates with an adjacent, external > bridge to provide bridging support between multiple virtual end > stations and external networks. The VEPA collaborates by forwarding all > station-originated frames to the adjacent bridge for frame processing > and frame relay (including 'hairpin' forwarding) and by steering and > replicating frames received from the VEPA uplink to the appropriate > destinations. > >May be implemented in software or in conjunction with embedded > hardware. > > > >Let me know if you have any questions. > > > >Regards, > >Anna > > > >-- > >Anna Fischer > >HP Labs > >-- > >Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks > RG12 1HN. Registered No: 690597 England. The contents of this message > and any attachments to it are confidential and may be legally > privileged. If you have received this message in error, you should > delete it from your system immediately and advise the sender. To any > recipient of this message within HP, unless otherwise stated you should > consider this message and attachments as "HP CONFIDENTIAL". > > > >> -----Original Message----- > >> From: nvrg-bounces at listserv.gwdg.de [mailto:nvrg- > >> bounces at listserv.gwdg.de] On Behalf Of Yoshifumi Atarashi > >> Sent: 29 July 2009 16:10 > >> To: nvrg at listserv.gwdg.de > >> Cc: OKITA Hideki > >> Subject: [nvrg-bof] virtual network management information model > >> > >> FYI > >> > >> http://www.ietf.org/proceedings/75/slides/opsawg-5.pdf > >> > >> -------- > >> Y. Atarashi
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.