I would prefer the phrase 'clear logical isolation' to 'clear isolation'. In my view a network is only 'clearly isolated' if there is separate hardware as in installations where different colored cables run through the different networks. I agree that VN-ish type configurations can be helpful in addition, but it is not going to be the case that isolation is an automatic security gain. For example, many folk who outsource their data centers happily develop networks with the standard firewall/dmz/firewall configuration and draw up pretty pictures, completely oblivious to the fact that the outsource provider has a control plane running between all the machines. On Tue, Feb 16, 2010 at 2:28 PM, Aaron Falk <falk@xxxxxxx> wrote: > A new IRTF research group on virtual networks has been created. Charter > included below. > > --aaron > IRTF Chair > > > ----------------------------------------------------------- > > > Virtual Networks Research Group (VNRG) > > > Chairs > > Joe Touch touch@xxxxxxx <mailto:touch@xxxxxxx> > Martin Stiemerling stiemerling@xxxxxxxxxxxx <mailto:stiemerling@xxxxxxxxxxxx> > > > Mailing List > > The email list is vnrg@xxxxxxxx <mailto:vnrg@xxxxxxxx>. You need to be a > list member to send mail to the list. To subscribe, visit the VNRG mail > page <http://www.irtf.org/mailman/listinfo/vnrg> or send an email to > vnrg-request@xxxxxxxx <mailto:vnrg-request@xxxxxxxx>. > An archive of the email list is available at VNRG mail archive > <http://www.irtf.org/mail-archive/web/vnrg>. > > > Wiki Site > > See http://trac.tools.ietf.org/group/irtf/trac/wiki/vnrg. > > > Charter > > A recent trend in networking is the concurrent use of a single physical > network for multiple variants or instances of networks, e.g., IPv4 and > some experimental protocol suite, or VLANs. These networks, called > Virtual Networks, provide isolation between network instances or types > and support shared use of the same infrastructure for different purposes. > > Virtual networks attempt to better utilize networking infrastructure by > reusing individual routers or links (i.e., either physical or logical > networking resource) for multiple concurrent network instances, or to > aggregate multiple such resources to obtain increased capabilities. > These resources can be any network component, including routers, hosts, > links, and services, (e.g., name mapping services). Increased capability > can refer to aggregate capacity provided by bundles of links or groups > of routers, or increased fault tolerance of a cluster of primary and > backup service systems. > > Important properties of Virtual Networks (VNs) are i) that each resource > can be used concurrently by multiple VN instances, ii) the clear > isolation of any VN from all others, and iii) abstraction, in which a > given virtual resource (host, link, router, service) need not directly > correspond to its component resources. These properties need to be > supported down to each physical component, such that each router, host, > and link supports concurrence, isolation, and abstraction. > > In the network community, "Virtual Networks" is a very broad term, > including running multiple wavelengths over a fiber, MPLS, virtual > routers, and overlay systems. VN technologies are widely used in parts > of the Internet and other IP-based networks, but the community lacks a > common understanding of the impact of virtualized networks on IP > networking, or how VNs are best utilized. As a result, virtualization > has been difficult to integrate across various systems, such as network > operators, vendors, service providers and testbed providers (e.g. GENI, > FEDERICA, etc). > > One current challenge with existing VN systems is the development of > incompatible or competing networking techniques in the Internet, causing > deployment issues in the future (or even now). For instance, there are > numerous ways to virtualize routers and their internal resources (e.g., > multiple, isolated routing and forwarding tables) and to virtualize core > networks (e.g. MPLS, LISP), but end host virtualization has not been > addressed (e.g., beyond the need for virtual interfaces). Few virtual > network systems allow a particular virtual machine in an end host to > control its attachment to a specific private network. The end host > virtualization architecture also determines whether virtualization is > per virtual machine, per process, or per connection -- and this > difference can determine exactly how the end host can participate in > VNs. Similar issues arise for virtual services, virtual links, etc. > > The VNRG will consider the whole system of a VN and not only single > components or a limited set of components; we will identify > architectural challenges resulting from VNs, addressing network > management of VNs, and exploring emerging technological and > implementation issues. > > Initial set of work items: > > * concepts/background/terminology > * common parts of VN architectures > * common problems/challenges in VN > * descriptions of appropriate uses > * some solutions (per-problem perhaps) > > The RG will initially focus on VNs but at a later stage the RG will also > be open to related topics, such as system virtualization. > > > Organization > > The Virtual Networks Research Group (VNRG) provides a forum for > interchange of ideas among a group of network researchers with an > interest in network virtualization in the context of the Internet and > also beyond the current Internet. > > The VNRG will encourage the organization of the work in smaller design > teams focused on specific areas of research. The design teams will use > the general mailing list in order to allow the broader community to > follow the evolution of their topics. > > Most of the communication inside the VNRG will be done through use of > mailing lists, however, the group will hold regular physical meetings at > least once a year in conjunction with IETF meetings. Additional meetings > may be held at IETF or other venues, such as in conjunction with related > conferences and workshops. Related meetings may include research > conferences and workshops, such as ACM CONEXT ReArch, IEEE Globecom > FutureNet, NSF GENI Engineering Conferences, ACM Sigcomm VISA; national > research efforts, such as NSF's Find, Japan's Akari, and the EU's > Trilogy, 4WARD, and Euroview, and related summer schools. > > The VNRG will produce Informational and Experimental RFCs in order to > document the activity of the group and to formalize the outcome of the > research topics carried by the group. In addition, such documentation > could become input to IETF working groups. The VNRG will also encourage > prototyping of virtual network technologies to validate this exploration. > > > Membership > > The VNRG operates in an open fashion (meetings & mailing list). > > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf > -- -- New Website: http://hallambaker.com/ View Quantum of Stupid podcasts, Tuesday and Thursday each week, http://quantumofstupid.com/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf